Pattern 9 – Find Mentors

This week I decided to learn about how to “Find Mentors” by reading the pattern. This pattern gives advice about why and how apprentices should seek out to find mentors to continue down the path to becoming a journeyman. They give tips about attending conferences, joining online forums, and taking your potential mentors out to lunch if you have the opportunity.

I do agree that finding mentors is greatly important in the development process to become a successful software developer, but I think this pattern idolizes a certain type of developer and therefore limits the opportunities for mentorship for those who try to strictly follow what the pattern is advising. This pattern seems to focus on those who are directly working on the development of a particular language, framework, tool, or some variant of open-source software. They even pretty much open with the idea that it is very likely that your mentors are not local and that you will likely never meet them. I think that this is where the pattern is failing.

From my experience, there is almost always someone, or a group of people within a company that those with technical positions turn to for mentorship and advice. At my most recent internship, it was a man named Kurt who has worked on the proprietary software (Oracle) before signing onto the company that we both worked for over the summer (TJX). He initially was a contractor from Oracle, but TJX found that his expertise regarding the frameworks that made up our software made him too valuable to let go of and they hired him full time. He immediately became the go-to guy whenever anyone had a question about our software. He had been working on it for over 15 years and had gone through over 10 iterations of the software. A key thing to note is that while everyone asked him for help, they weren’t asking for mentorship. This is something that came with my internship as he was selected to be my “buddy”, which was just a fancy word for mentor. We spoke several times throughout the summer about both career goals, and different ways to solve problems. We spoke about how to solve certain problems that were specific, yet more general than our specific code base. To get this kind of mentorship, I didn’t need to lurk on an internet forum, and the same went for everyone I worked with that wanted to learn from him. All I had to do was ask. There will likely be a Curt everywhere, any of us end up working, and I plan on utilizing their mentorships.

My final 343 Post: Abstraction

For the last couple of weeks, I’ve revisited a couple of the most important concepts of Object Oriented Programming, Polymorphism and Encapsulation. This is my final post for my CS-343 blog entries, and I have decided to continue in this trend. Today’s topic is Abstraction. This week I’ve gone to a favorite resource of mine, geeksforgeeks. Their article on Abstraction covers almost every question that comes up with Abstraction.

I feel it is best to first specify what an abstract class is, and how to make use of one. In Java, an abstract class is defined with the abstract keyword. An abstract class cannot be directly instantiated because of the abstract methods inside the class. An abstract method, is a method that does not have an implementation but must be present in all children classes. This is done via overriding the method(s) in the children classes. Only one method has to be abstract, meaning that there may be other methods that have complete implementations that are reused in their entirety by children classes. Similar to how we implement an interface, we extend abstract classes.

Like my other blog posts, I feel that the best way to learn a concept, is through examples. More importantly, the examples need to be practical, and ones we can relate to. For abstraction, the article on geeksforgeeks uses the classic Shape example that we’re all familiar with.

Our abstract class is the Shape, with three methods and one variable, or attribute. Each Shape has a color, getColor method and two abstract methods, area and toString. A Shape fits exactly into what an abstract class should have, and shows exactly what we can know, based on the object simply being a Shape. A Shape has to have a color, but the formulas for finding the area are different depending on the type of Shape, and the same goes with the toString method.

The children classes presented in the example are the Circle and the Rectangle. The UML from the original article even shows the extends declarator for the children classes. It’s important to note that the abstract methods are not rewritten in each of the children classes. This is because we have to implement them, and thus, they are carried over when we apply the extends declarator. The only new pieces of information in the UML are the attributes we can use for our abstract methods, radius for Circle, and length and width for Rectangle. As seen in the code blocks below the UML, these are used to calculate the area and then the toString.

Abstraction is one of the most important tools that any object oriented developer must have in their toolbox of concepts. This is used in almost every full scale application and often numerous times throughout. A lack of understanding of abstraction will lead to failure to excel in the software engineering world.

Original post here: