(no title)
nerdy | 8 years ago
For example, if you're trying to teach TDD strategy then pairing might be best because there's a lot of nuance to how things are done. Environment setup. Tests come first. Make sure all the tests pass before moving on. Refactor between. So for TDD it would be difficult to provide a big list of dos and don'ts and expect someone to navigate them.
Some skills are contextually less rigid than TDD. Debugging a problem for example: if a developer is trying to use an internal API but they are getting a timeout response instead of any actual output. You could simply tell them to see if the HTTP server is running, but it's probably better to ask questions and explore the problem vicariously. "What do you think the problem could be?" Then you can arrive at gaps in their understanding about how the system or HTTP servers work.
Asking questions when there's that too-familiar "we've gotta get this stuff done" atmosphere can be challenging. It's tempting as a senior developer to just provide the answer without slowing down and exploring the problem with your junior counterpart.
There's also institutional teaching. Is the junior developer asking questions which should be addressed in documentation? If so, you should probably commit those answers to the documentation and have the developer act as a litmus test for the completeness of the information.
So teaching can be showing, sometimes it's a matter of explaining, and other times it's more important to just ask the right questions. I think one of the most important parts of teaching is perspective-taking. You want to explore the areas just adjacent to the person's knowledge.
Also, blameless postmortems. It's easy to point fingers when shit goes wrong. Don't.
Developers junior to me ask questions which I find border on alarming sometimes but I suppress that reaction because I would rather fill those dangerous gaps than have a developer be too scared to ask.
No comments yet.