Ask HN: How do you teach/enforce programming best practices?
3 comments
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.
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?).
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?).
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.
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.
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/.
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.
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.
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.
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.
What techniques/rules have you implemented that help teach devs the importance of things like: SOLID Principles, Law of Demeter, Principle of Lease Astonishment, etc.?
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.
In my experience this has been a common theme across environments (both large and small) that I have dealt with and I'm very curious to hear how others are handling it.