Find Mentors

When first understanding how you learn, and the general experience of how human beings learn, you’ll find yourself in a situation where you want to learn something, but you don’t know how to go about learning it. You take your first stab at it and find that you are learning some things but not learning constructively. You blunder around accumulating random knowledge and at some point, you might experience some success and get lucky. But more times than not you’ll blunder around and this effort might demoralize. The fault was not in your but your methods.

Mentor-ship and finding mentors is critical to learning something more specialized within your own skill set. This apprenticeship pattern perfectly describes an issue that I have frequently run into myself. It describes this path as exploring a blind alley, and this is an apt description. During my first sprint during my computer science capstone I made an effort to try and learn HTML. I looked over some example code and learned generally how to write it but fundamentally I didn’t understand how to structure it. I was blindly exploring the learning process and was failing.

I felt how I was failing and I knew I needed to reach out to something far more similar to a teacher. Some see the name mentor but what is a mentor but a highly skilled teacher. Yes of course there is more to teaching than just knowing the skill but they have the knowledge of learning the skill you are trying to and the path that helped them succeed. You need to find yourself a path that has been traveled by a human instead of blindly traveling that avenue.

I sought an actual HTML course that is commonly available in YouTube format and learned in a structured manner from a person who understood it as a whole. Now this isn’t to deter you from learning something new without a mentor as you do need the ability to learn new things without help, but something completely foreign to you requires a teacher. Mastery of a subject will require a mentor. Both require a desire to learn and to realize when you should seek other’s help.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

The context given here is that You have been an apprentice for a little while. You know a few things and people are starting to look to you as a source of knowledge. Up until now, you have focused exclusively on your own improvement as a craftsman. To become a journeyman, you will need the ability to communicate effectively and bring other people up to speed quickly. A good way to prepare you for that is to develop the habit of regularly sharing the lessons you have learned. This may take the form of maintaining a blog or running “brown bag” sessions amongst your peers. You can also make presentations at conferences or write tutorials for the various technologies and techniques that you are learning.

The books highlight that Being part of a community of individuals where both learning on your own and humbly sharing that newly acquired knowledge are valued is one of the most powerful aspects of apprenticeship. It makes otherwise-esoteric fields of knowledge suddenly accessible, and provides apprentices with guides who speak their language. That being said some lessons should not be shared, and it’s important to keep in mind that there is an ethical dimension to knowledge. Before sharing something, consider whether that lesson is yours to share. It may be a secret, or it may harm others. Things that seem obvious to you because of your current context may in fact be your employer’s “secret sauce” and it is all too easy as an apprentice to overlook the consequences (legal, financial, and political) of sharing that knowledge.

I can personally relate to the content in this pattern because I have worked for 2 years as a tutor for introduction to programming class (java) and it has helped me on so many levels. I remember my first instinct was to decline the job when the position was first offered to me. But then I took “a risk” and started working as mentor and all of a sudden, my understanding in the class material got better. I got comfortable sharing knowledge in an effective way, and I got great public speaking skills

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

The context given here is that as a result of your dedication to learning, you have been hired or promoted (formally or informally) into a position with a title containing words such as “senior,” “architect,” or “lead”. The problem is then that your job title doesn’t match what you see in the mirror. When you introduce yourself in a professional setting, you feel as if you have to apologize or explain away the difference between your skill level and your job description. The solution suggested is not to allow your title to affect you. It is a distraction that should be kept on the outskirts of your consciousness. Use your title to gauge your organization, not yourself.

Impressive titles and responsibilities do not indicate that your apprenticeship is over. They only serve to remind you that there is a shortage of craftsmen in our industry so we should not be fooled by an impressive title. Another variant of this theme is informal versus formal titles. For instance, you may have grown into a position of authority on your team, despite your formal title remaining the same. These informal titles can be hard to ignore, because they are constantly reinforced by your peers, even if they conflict with your self-assessment. During these times, your connections with your mentors and peers will be critical to keep you grounded in reality.

I was really glad to see that the title subject was tackled in this book. So many times, I have found myself in jobs doing way more than what my title said sometimes even doing something completely different. In my current position, I am doing my job and some part of the data analyst job and at first, I got slightly annoyed but I have now realized that I would try to learn from it as much as possible rather than complain about it

I also really liked their action plan which is to Write down a long and descriptive version of your job title. Make sure it accurately reflects what you really do at work and your skill level. Keep this updated, and from time to time imagine how you would view a stranger who had this job description.

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

This pattern encourages us to go beyond the surface level work. The context given is that You live in a world of tight deadlines and complex software projects that use a multitude of tools. Your employers cannot afford the luxury of employing enough specialists to fill every role. You learn only enough about any tool to get today’s job done. You select a handful of tutorials on the language or library that you’re working with today and consequently You make decisions without taking the time to understand the issues, and copy the toy examples provided with the tools. The problem is then that You keep running into difficulty maintaining the code you’ve written because it turns out that the tutorials you followed cut corners and simplified complex issues. You find that your superficial knowledge of a thousand tools means you’re always floundering whenever a subtle bug arises or you have to do something that demands deep knowledge.

The solution suggested is now to Learn to dig deep into tools, technologies, and techniques. Acquire the depths of knowledge to the point that you know why things are the way they are. Depth means understanding the forces that led to a design rather than just the details of a design. In other words, it also means understanding type theory rather than simply parroting the things you’ve heard others say. I agree with what is being said because the areas where you have deep knowledge feed your confidence and they indicate places where you can deliver value early in your time with a new team. More importantly, this depth of knowledge is something you can fall back on to give you the strength to tackle new areas.  I have mentioned before how I usually run straight to google or StackOverflow in time of doubts but 95% if the time the website only provides “quick fix” type of answers and there is no real learning happening. I have understood that applying this pattern regularly, will help me truly understand how my tools work and I will no longer just be gluing bits of code together and depending on other people’s magic to do the heavy lifting.

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.