Tuesday, October 19, 2010

Mentorship Apprenticeship Program

In the previous post I wrote that as part of our next Software Craftsmanship meetup I will establish and start the enrollment process for a Mentorship Apprenticeship Program.

Since then I received quite a few emails and questions regarding the program and decided to summarize the answers in a Q&A form.

What does the Mentorship (Apprenticeship) program stand for?
How does the Mentorship (Apprenticeship) program work?
How a Mentee finds/chooses a Mentor?
What is the Mentor's responsibility?
What is the Mentee's responsibility?
What is the minimum period of the Mentorship (Apprenticeship) Program?
Can a MenteeMentor leave in the middle of the Mentorship (Apprenticeship) program?
What happens at the end of the Mentorship (Apprenticeship) program?
Can a Mentee and a Mentor to be from different companies?
Should a Mentee and a Mentor have the same technological background?

Q: What does the Mentorship (Apprenticeship) program stand for?

A: We all find ourselves looking for a Mentor to guide us throughout our work. Software Development is a hard profession to master and having a Mentor who can teach us, review our decisions (code, design, architecture) and throw light on different technological/management matters will no doubt enhance our knowledge, skills and capabilities. Moreover, it is my strong belief that such a program will be of benefit to the software development community as a whole.

Q: How does the Mentorship (Apprenticeship) program work?

A: A Mentee will select a Mentor who should accept the mentee as his apprentice, and the mentor will act as his guide for a minimal Mentorship (Apprenticeship) period.

Q: How a Mentee finds/chooses a Mentor?

A: As a part of our Software Craftsmanship in Israel Community, I will maintain a list of Mentors. The list will be constructed primarily based on the community feedback. A Mentee will approach a Mentor from the list based on the community feedbacks and his best impressions from the Mentor's capabilities, publications and etc... Should the Mentor be available, both the Mentee and the Mentor will commit to each other for at least a minimal mentorship (apprenticeship) period.

Q: What is the Mentor's responsibility?

A: A Mentor will:
  • Provide Technical Guidance and Feedback.
  • Provide Reading Sources.
  • Review and Build Career Paths.
  • Hold Code Reads, Code Reviews and Pair Programming.
  • Conduct Architecture and Design Reviews.
  • Review Management Decisions and Advise Management Dilemmas
  • Anything else that will be agreed between the Mentor and the Mentee.
  • Provide feedback to the community.

Q: What is the Mentee's responsibility?

A: A Mentee will:
  • Learn, Learn, Learn.
  • Provide feedback to the community.

Q: What is the minimum period of a Mentorship (Apprenticeship) Program?

A: Four (4) months. Each Mentee and Mentor may together decide at the end of the period whether they wish to extend the period which, in my opinion, should be longer.

Q: Can a MenteeMentor leave in the middle of the Mentorship (Apprenticeship) program?

A: The whole purpose of the mentorship (apprenticeship) program is the commitment that both the Mentee and the Mentor make towards each other. If you cannot commit, I suggest you do not enroll in the program. I suppose that there will be exceptions, but those will be exceptions to the rule.

Q: What happens at the end of the Mentorship (Apprenticeship) program?

A: At the end of the mentorship (apprenticeship) program a Mentee can choose another Mentor. Eventually (after being in several mentorship programs) a Mentee will be ready to become a Mentor himself.

Q: Can a Mentee and a Mentor to be from different companies?

A: In my opinion, not only is that possible, but also advisable.

Consider, what is there to gain:
  • Other techniques, technologies and approaches.
  • An objective view that teaches and directs, without any fixations on the solutions and approaches being applied within your company.

But, what about intellectual property (IP), will you ask?

At least from my point of view (and I have seen quite a lot of solutions from different companies), most of the issues, ideas and code aren't original, nor patentable. The architectures and the designs are pretty much the same, the issues and even the implementations are often identical and most of them are very well known and in the public domain. Companies like Facebook, eBay, Twitter and etc... freely talk about their architectural decisions and implementations; So, why we should we be different?

Nevertheless, there might be some unique business rules or algorithmic ideas being employed by a company and in such a case, please don't discuss those. Use your best judgment and if in a doubt, refrain from any discussion of those points. There will be still plenty of issues to deal with.

Q: Should a Mentee and a Mentor have the same technological background?

A: Not necessarily. It totally depends on the Mentorship (Apprenticeship) program's intention. If a Mentee wants to learn a different stack of technologies - then that might make sense. But if a Mentee wants to increase his knowledge of the current stack, it makes sense to approach a Mentor with the same technological background.

Monday, October 4, 2010

Software Craftsmanship Podcast



Here you can find a short podcast I recorded with Ran & Eran from Reversim; The subject is Software Craftsmanship in Israel Group (in hebrew).

(mp3 is here.) 

Many thanks to Ran, Eran & Ori !!!

Fourth Meeting of the "Software Craftsmanship in Israel" Group

On 18.10.10 at 18:30 we will conduct our fourth Software Craftsmanship meeting.

The agenda is:


Introduction:

  • Introducing Mentorship / Apprenticeship Program.

I (~40 - ~60 min) - Lectures: 

Each lecture will be up to 20 min.

Depending on the time, we will have 2-3 lectures.

  • Structure 101

  • Effective Code Reviews - How?

  • "Legacy" Code & Unit Tests

II (~80 min) - Coding Dojo:


  • Demonstrating Pair Programming (Randori Style). We will write a small program, evolving its design and tests.

If you have a laptop with your environments set-up, please bring it to the meeting.

Please register on LinkedIn event or on Eventbrite event (next time only Eventbrite :) ).

The meeting will take place here.

Saturday, October 2, 2010

The Importance of Mentorship

(Cross post from IRefactor)

It's hard to become a professional. It's even harder to become a professional Software Engineer.
Last week, during a small management conference I bumped into an old friend of mine, who I didn't see for a couple of years. Being a leader of a software engineering group, he was frustrated and worried:
"I have a group of 20 people, working hard to meet harsh deadlines. The project has just started, but most of the software engineers are already not pleased. There are junior developers that consider themselves as senior developers, there are senior developers that consider themselves as team leaders and there is no uniform professional knowledge. All of these are affecting the product's quality and really hurting our work."
Although there are many ways to shape cohesive and gelled teams, there is one important notion that just lately received its attention: Mentoring.

The professional life of a Software Engineer is rather sporadic.
Most of us are drifted with the stream. The lifecycle is pretty much the same; You find a job, you receive features or requirements to implement, you code, you debug and then you move on.

But, have you ever felt that if mentored by a true professional you would succeed more?
You would know deeper. You would decide better. You would have better choices of your career paths.
I reckon that most of us did feel the same...

Moreover, good mentors, not only promote individuals, but usually create around themselves a great environment (and therefore great teams).
Excellence drives excellence and professional excellence usually directs all the team members to shared ownership, partnership and targets.

However, it is hard to find a true professional and it is even harder to find a true professional that knows how to mentor.

There are a lot of parameters that shape a mentor, but no doubt the first virtue will be experience: Experience of successes, experience of failures and experience of crisis-es.
Those are true Software Craftsman, that spent their days and nights in polishing their skills.
And being masters in building and managing software, they can teach you a lot: How to write good requirements, how to architect, how to design, how to produce clean code, how to build software, how to ship software, how to manage technological teams, how to receive better technological decisions and etc... and etc...

There is much more to say about mentoring. I will dedicate a few posts in the future, to describe what are, in my opinion, the virtues and the ways to do it well.
However in the meanwhile, I would like to take up the glove I have thrown in this post... On our next Software Craftsmanship Meetup, I will enroll a Mentorship program.

A Mentorship program will allow Mentees to find an appropriate Mentors.
The mentorship period will be for at least 4 months (IMHO, it should be more than 4 months, but let's start with that period).
During the mentorship period both the Mentees and the Mentors are committed to each other.
They will meet for at least 2 hours each week in order to:
  • Provide Technical Guidance and Feedback.
  • Provide Reading Sources.
  • Review and Build Carree Paths.
  • Hold Code Reads, Code Reviews and Pairing.
  • Do Architecture and Design Reviews.
  • Review Management Decisions and Advise Management Dilemmas
  • Etc. . .

If you are not coming to the 4th Software Craftsmanship meetup, but still want to participate you are most welcome to contact me via the blog.