In this final installment of my individual apprenticeship patterns, I think an important one to write about would be Find Mentors. To summarize the main point of this one, I would say that it encourages people to observe their role and their surroundings to see where they can find the most value from learning or use their resources. It encourages you to look at things from one level back instead of blindly jumping into something right away.
Personally, I have been in a role where I had to figure out a lot of things that could have just been taught to me. I quickly learned that I would be able to ask other junior developers how they managed to learn things on their own and it helped me a lot. If other junior developers were not available, then I would work my way up to people who had the most recent on-boarding experience and hope that they could recall the process I was currently going through. For the most part, that worked out well!
Thanks to this pattern, I thought it was useful to think about and remind ourselves that even though our mentors will know a lot more about us, they still do not know everything. They are still continuing to learn as much as we are in their own careers.
I thought I should update this blog to throw in a little hidden announcement if anyone actually reads these that I will be learning at a company with about 100 peers going through the same thing. This makes me feel a lot more confident knowing that I will have a designated support system around me and have mentors around.
Overall, I agreed with the pattern. This is because I can testify with my personal experiences how useful it was to be able to utilize my resources including being able to ask mentors questions or just find my own. A common question I had for my interviewers was, “Will I have a mentor or support system along the way throughout my career progression?” Personally, it is important for me to have a designated place to go for support because it just takes one more worry away about having to ask somebody a question.
It is now time to conclude my individual apprenticeship pattern series! I hope you have at least learned one thing from it because I have learned so many things.
From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.
Testing, testing. I may need your approval on this article I read by Software Testing Magazine on Approval Testing. Approval testing, as defined by this article, is a way of software testing that results in presenting the before and after of an application for a user (ex: software development team) to review it and potentially approve it. It’s more of a visual representation of testing and one of the major cons is how the results have to be checked manually.
When coding, users always have to be conscious about the way their code may be implemented or used in the future by different services leading to potential misuse. After reading Code Health: Make Interfaces Hard to Misuse by Marek Kiszkis, it made me think about how important communication between testing code is.
It is also good to remember that at the end of the day, code should be defensive but not too defensive to the point that complexity is increased and performance overall is reduced. Kiszkis says “it is not always practical to have a foolproof interface” because there will be situations where some requirements are things that cannot be expressed in an interface.