My first steps as an embedded software craftswoman

I participated in consultancy projects a few years ago, but they were the typical ones. We would visit a company for a few hours over several days, they gave us the information they thought was useful for us, we asked questions and more details and then we created a plan to help them by:

• Giving guides to solve what we knew about their problems
• Adapting internal tools
• Giving training courses

Soon, I noticed that this approach was only partially useful. When I re-joined a company that I had helped previously, I realised that we hadn’t understood their real problems. When you are inside a company you “feel” its problems, you really know the reasons behind those problems and you have a very different perspective to help you understand possible solutions.

I joined Codurance a few months ago, a very different consultancy company. After a period of apprenticeship, absorbing the principles, values and practices from Codurance, I started working as an embedded software craftswoman. That is to say I’m a member of one of the teams at a client who wanted to improve the quality of the software that they produce.

It has been a rewarding experience, because I have the opportunity to see the improvements in the team, "living" with them, while I continue to be a member of an awesome group of people that gives meaning to Codurance, who are always available to help, to share, and to learn with me.

I call it “consultancy from within” and it changes the negative meaning that “consultancy” usually has in Spain.

In the client company, I work as a member of the client team, but with a special focus on mentoring and transmitting knowledge and a different way of doing.

I love this article from Christophe Schreiber: The benefits of having a craftsman in your team.

Here you can find some of the things I’m doing in my new team, beyond well-known practices such as pair-programming and code-reviews.

Different formats for “Lunch & Learn”

We have a Lunch & Learn session every week for two hours: lunch hour plus one hour from working time. We usually try different formats:

• Watching a video: it’s paused from time to time to discuss our understanding
• Reading articles and sharing what we have learnt at the end of the session
• Demos to share with the full team what a pair of us has learnt
• Talking about the last conference we have attended

This week I've tested another format. I called it Hack Lunch:

1. I proposed several subjects to practice
2. Each pair (myself included) chose one subject and wrote the choice on board to avoid duplication
3. Each pair practiced and chose another subject if there was time
4. At the end, each pair showed the learning (very interesting discussion)

Next time when we practice this format, we will take our own subjects of interest to the session.

Challenges

I took the opportunity to review concepts of Git during a Lunch & Learn session. All the members of the team used Git, but sometimes they had doubts and I wanted to reinforce the knowledge. At the end of the session, they felt that they had learnt a lot and they wanted to continue practising. “What do you think if I prepare small challenges to practice on your own and we share the results in two weeks?”. They agreed.

A few days before, Kilian Jornet scaled Mount Everest and I think the idea of challenge came from it.

I prepared a challenge to each one with the following goals:

• To practice
• To have something to teach other colleagues to enhance their knowledge
• To master development tools

It was a great experience and we’ve had more challenges since then about other subjects. Now, each time we find an interesting subject and we want to continue practising, we prepare challenges.

We have two weeks to solve challenges and then we have a final session to share results. I think it's a good way to motivate them and to solidify the knowledge:

• First, learning together
• Second, learning alone with challenges
• Finally, sharing results

“Cooking with Rachel”

I like to make things funny and I chose that name to represent an informal and short training session to teach small things to the full team, starting with the sense of smell. It’s useful to emphasize the comments that we make during code reviews.

Finally, I would like to thank my new team for the warm welcome. They are very good people and it’s been a pleasant and fruitful experience for me. Thank you!