When mentoring apprentice software craftsman there are times when rationale gets lost. You are trying to teach them caution. Caution means slowing down and being attentive to your surroundings so you don't do something dangerous. But if they never get hurt can they really understand why they should be cautious?
It's different with children. You don't want them to use the stove or run with scissors because the cost of not being cautious is too high. But you let them spin around like a top until they fall down, potentially getting a bop in the head. You let them have a pillow fight, knowing that someone is going to come screaming in a few minutes. Why? Because when they get hurt they learn a valuable lesson.
In software, how do you gauge what is an acceptable risk? I remember several years ago working with a group of junior developers and getting them to write unit tests. I was a broken record: "You have to write your tests." "Did you write your tests?" "You can't refactor without tests." "Did you run the tests before checking in?" "Did you run the tests as soon as you checked out?" ... but they had never really felt the pain of not having tests or dealing with poorly written tests. It was nearly three years later when one of the developers came to me and said "You know I finally get this unit testing thing now. I just did it before because we were told to, but I never really understood why. Now I do." Almost instantly, all the light bulbs went on for him. Short iterations, the importance of enforcing a coding style, the use of Fakes & Mocks ... it was easy to see he was no longer a junior developer. Testing was a part of his craft now.
Is there anything more I could have said to make this more evident? Probably. But I think the words would have been lost or come across as more preachy than it always was. He needed to feel the pain for himself to learn.
But ... as a manager, could we afford to have developers not doing tests for three years? not complying to the coding standard for three years? No. We had felt the pain. We know what the costs of not doing that stuff is. I'm sure many of the tests written during his journeyman-ship weren't very good ... but they were building muscle memory. I'm sure many master carpenters, glassblowers and potters do things by rote for a long time before really understanding the subtlety of their actions.
Being a mentor, just as being a parent, you have to make the hard decisions of when your charges are really going to hurt themselves and when it's ok for them to take a smack in the head. And, often times, explaining why beforehand gives no benefit.
3 comments:
Well, it's like a well-known psychologist says, "your kids may roll their eyes or pretend to not hear you, but they're always listening."
I think the same is true for Software Developers. Eventually,when the light bulb comes on, they will think it was their idea.
Although I think I agree with you in this case, I would have difficulty applying this in general terms, especially when it comes to developers. Good developers are, or at least should be driven by "why" and "what"...they study "how" but that may be another post.
In my (humble) opinion, developers that dig for "why" will usually build useful things since people tend to be vague with the "what" part of exactly what they want. "Why" is a clarifier for "what" and unless developers start asking "why" then they just work on like drones and never really produce the result that people are looking for.
I often find myself working with junior developers that don't "get it" when it comes to testing in particular. I think preaching is the natural reaction, but if you take the time to think about the "why" for testing in real terms: stable code, cleaner code, understandable code; you can come up ways to measure these outcomes and then hold developers to these measurable standards while enforcing the "test first" way of doing things.
At the end of the day, if it comes to it, you may have to resort to "just do it!" but I think taking the time to be able to articulate the "why" in measurable terms yields pretty good results.
@Shawn, you're absolutely correct. You do need to give your rationale for applying a process. I should have made it more clear in the post that this was done ... probably not well enough. :-)
It's hard to illustrate the impact of fragile tests until they've been bitten by a false positives or long running tests. You can show what a false positive is, but not the anguish of having to find them during a pre-release iteration.
I'm not implying the developers don't want to learn. They certainly do ... otherwise they wouldn't have been hired. But coming into a new environment and getting a fire-hose of knowledge in the face can tend to make these sorts of things get lost.
It's why I think the "hold off on commit bits" (older post) rule is so important. It forces you to take the time, review the code and impart the knowledge so that hopefully it doesn't take 3yrs for the important stuff to sink in.
Thanks for the thoughtful feedback.
@Mike, I like the idea of making them think the idea was theirs. Always a good negotiation tactic!
Post a Comment