

Ask HN: How do you teach/enforce programming best practices? - unfug

Since finding a work environment where you work solely with top-level talent is exceedingly rare (especially outside of tech-hub areas), it&#x27;s important to figure out how to maximize the talent that you have available.<p>What techniques&#x2F;rules have you implemented that help teach devs the importance of things like: SOLID Principles, Law of Demeter, Principle of Lease Astonishment, etc.?<p>I work in a fairly standard corporate environment. Initially we tried to just enforce these things solely through code reviews, but it seems like they just mechanically make the suggested changes without really learning why it matters. Even most junior devs seem to have an academic grasp of things like the Single Responsibility Principle, but at some point during implementation that falls apart.<p>In my experience this has been a common theme across environments (both large and small) that I have dealt with and I&#x27;m very curious to hear how others are handling it.
======
brudgers
In my first CAD job, the way standard practices were ingrained was by having
junior team members, i.e. me, be assigned to check the work of more
experienced team members. It got fresh eyes on established habits, it exposed
me to more complicated work and hence more complicated issues, and made
reviews a two way street - I learned to see things through the eyes of those
reviewing my work, and those further up the food chain did not get a free pass
to the idea that the-right-way-is-whatever-way-I-do-it.

~~~
unfug
That's an interesting idea. Did the original author of the work walk the
junior team member through what was going on, or did they just point them at
it and have them check through the work on their own?

It seems like that could be helpful. My main concern is that a lot of junior
devs need some specific direction (as opposed to just telling them to go read
some code) so we might need to setup some specific expectations for the
results of the code review (maybe have them help write documentation?).

~~~
brudgers
In the situation I described, review [of drawings] was part of the QA process,
and going through the QA process was a requirement before anything was
"shipped" [sent to the plant for fabrication]. So all that happened was that
the normal roles for junior and senior staff were reversed for a small portion
of the normal work-flow [i.e. a senior staff member did a lot of QA and a
little production and a junior staff member did a lot of production and a
little QA].

If review was just something that was done sometimes [and those sometimes
being either slack periods or seen as part of correcting a situation in need
of remediation] then it would not have made sense. It was only due to the fact
that the junior staff member's sign-off was required "to ship," that the
process was meaningful.

One of the side-effects was that some of my wild and crazy ideas that arose
from not knowing any better were identified as seriously off target. Another
side effect was that some of those wild and crazy ideas got adopted as
standard methods because they worked and improved workflow.

If it isn't clear, I don't think code review assignments as punishment or busy
work are worth pursuing.

------
zachlatta
I've found that detailed code review before code makes it to master helps
enforce these principles and sets a precedent for future code. Gerrit is a
nice tool for this
[http://code.google.com/p/gerrit/](http://code.google.com/p/gerrit/).

~~~
unfug
We're currently transitioning away from TFS and I think locking down changes
to pull requests (and potentially blocking most devs' access to commit to
master) will help quite a bit. You can pull off a similar workflow in TFS,
it's just much less convenient.

I think being able to see the full end-to-end diff for a task/story (as
opposed to digging through a series of changesets in TFS) will make the
benefits of any suggested refactorings much more obvious.

------
pasbesoin
By example. Seriously.

I've been plenty of places where the edicts are passed down to the... "little
people". They/we can end up jumping exhaustedly through endless rounds of
process.

Then, the shit hits the fan, or a senior manager simply can't be bothered, and
process is suddenly out the window.

Imagine the impression that leaves on everyone who's been running the process
maze.

Demonstrate that it matters and serves a purpose. And keep it sane.

All the rest is just talk.

