https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s08.html

This pattern encourages the reader to pay close attention to minor details along the way when evaluating a success or failure. Apprentices commonly find themselves in complacent situations in an average team, so naturally improvement stagnates and it becomes hard to keep yourself on track. The problem is, “the less skilled you are, the worse you are at assessing the skills of yourself and others.” This indicates that it is especially hard to get started again once caught at the bottom of the barrel.

The pattern advises seeking out feedback and constantly adjusting yourself accordingly. This will help you more accurately predict success or failure and help you more efficiently improve. Being open with your work is the focus of other patterns, all apprentices should strive to be as “teachable” as possible.

The chapter classifies feedback under two categories; reinforcing and balancing. Reinforcing feedback encourages more of something, while balancing feedback encourages less of something.

In my personal case at work, I can apply feedback to the pitch I give to the average customer. For the most part, my pitch is designed to be friendly and get the customer the product they are looking for quickly. In that time, I work to fit in other deals or offers I think the customer might be suited for. This could mean higher quality products, the benefits of the best buy credit card, or becoming a member of our total tech subscription service.

At the end of the month, we are provided feedback on how much we sold and how many cards or subscriptions we put out. Some months are luckier than others, but certainly every associate starts to get better and better over time. If an associate doesn’t raise enough revenue after a few months, they receive coaching on their style of pitch. Reinforcing feedback in this case would encourage an associate to mention the subscription service to more customers, thus increasing the chances of closing one. Balancing feedback would prevent swearing and acting rowdy with coworkers in front of the customers, in an attempt to be more approachable.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

Whenever you are new to a team, it an be very nerve racking because you do not want to mess up a single thing. This mindset is perfectly normal and makes sense.  This pattern discusses newcomers into a project and what to do in this environment. For starters, it’s always important to make good relationships with your team. The situation is that you are a new apprentice on project and the team is unsure of you. You want to find ways to contribute to the teams work but you can’t overdue it. This pattern explains that y ou should volunteer yourself for simple but necessary tasks. There are always going to be certain tasks that your team will need to get done one way or another, and even though they are simple tasks, they can often enable for the future success of whatever project you are working on. When taking these tasks, you should still pump out a high quality job. Showing that you can perform even basic tasks at a very high standard of quality shows your team that you care about what you are doing even if it is just small tasks. Sometimes these tasks can be just as vitally important as other tasks. Some examples of these tasks are maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, or even setting up the project wiki. However, it can be tough to do if you spent a lot of time and money on computer science education. The reality of it is that when you get into the workplace, our education is worth a lot less. When you join a computer team, getting hired is different from joining a team. Your firsts takes should be made to send a message. However, there could be some potential downfalls to this pattern. It could keep you permanently doing these mundane tasks for the team and never giving yourself a chance to expand to bigger and better things yourself. But if you do the tasks that sometimes your team may not want to do, it could give you a sort of priority on what you can do next for the team and open new opportunities for your team to see how worthy you are.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

The section titled Find Mentors discusses finding people in your field who are seasoned and have a lot of experience to offer, and to reach out to these veterans of the field and try to gain from them what knowledge they have to offer. It is a simple idea, but as the text explains, it is intimidating to just ask someone to offer their services and mentor you. It is a lot to ask, and not everyone is up for it after all. Besides, it is challenging to know who is even a good mentor, and who is not.

I consider many of my professors at Worcester State mentors to an extent. However, I wouldn’t say I’ve ever had the kind of mentor-ship detailed within the section. I can definitely relate to the anxieties listed about reaching out to someone. It can seem weird and uncomfortable. I suppose it is just a feeling you have to conquer if you want the best for yourself, however. After all, nobody else is going to ask for you.

From my perspective, Find Mentors is such an important pattern because there is a limit to how much most people can learn independently. There is such a huge advantage to having a resource like someone who has been through all the challenges you are facing and can solve some of the problems that come up. I hope that in my future I have the chance to meet someone who can offer me these advantages. Actually getting into the field is a huge hurdle, and having someone who has been through it and could coach me on how to navigate it would be incredible. It is just something I am going to have to search for.

Overall, Find Mentors seems like one of, if not the most important apprenticeship pattern I’ve read about and discussed so far. After all, finding a compatible mentor that is willing to dedicate the right amount of time for you would result in huge growth and development. It is hard to obtain this ideal, but it is something worth striving for.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

For this weeks blog post I will be discussing the pattern known as “Sweep the Floor”. Sweeping the Floor is about you starting from the bottom and then getting into the more complex tasks. This being you contributing to simpler tasks, learning from these and becoming more skilled then graduating into larger more complex tasks. Imagine you are an new apprentice on a project, unsure where you stand compared to others on the team and they are unsure about you as well. You want to earn your place on this team, contributing where you can, gaining their trust and growing in the craft essentially. To do this you could simply volunteer for something simple that is necessary to complete. This is a good starting way to contribute to a foreign team and to the teams success early on by showing you can do high quality jobs even for simple matters. Skimping on quality here could lead to trouble later on when it turns out later that this part is actually very important. Some various examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, setting up a project wiki and so forth. Basically you would be focusing on the edges of the system where less risk lies rather than the heart of the project where the stress and complexity would be. But this of course could prove tougher to swallow if you have spent a lot of time and money in a computer science degree. The moment leading up to your career in theory has been doing all of the said above tasks almost just without pay. Another negative aspect of this would be you ending up as the teams gopher, condemned to do menial tasks no else wants to do. You may find yourself intimidated by doing anything other than sweeping the floor, feeling only comfortable doing this. There is also danger in that you may not be able to develop appreciation for bigger projects due to the smaller menial tasks you are accustomed to. In short finding the tasks nobody wants to do or complains about and creatively resolving these problems in ways that exceed peoples expectations will allow you to slowly soar above, something that most including myself can get behind.

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

For the tenth and final week of reading, I chose to read the pattern, Use the Source. This pattern focuses on the problem that without the presence of good source code to study, practice, and emulate, you can’t get better, and you might continue developing bad habits you didn’t know you have. The solution provided is to find another person’s code and start reading them. This will enable you to learn how they wrote their code and understand the thought process that made that code. The recommendation includes examining open source projects and examining them for why they work in such a way. Also, to attempt and refactor codebases to understand the decisions programmers make and why they didn’t choose a different way. This process also leads to why there is appreciation for code reviews and pair programming. Having other people read your code, you read theirs, everyone can learn from each other. Allowing yourself to get a feel for good and bad code, you can develop a better understanding of yourself and how to improve.

This pattern is interesting because I never thought about using open source projects as a way of learning. I always took open source projects as a way of getting things from the community and as a way of contributing back to the project. However, using it as a way of reading well maintained code, reading practice, and understanding the thought process is a creative way of using publicly available projects.

This pattern is also useful because once you have seen the code, you might remember it for later as the code is not textbook examples. Examining, dissecting, and understanding code from real world projects allow you to see more, retain more, and most likely apply it in your own code later on.

The pattern has caused me to change the way I think about my intended profession because there are many different ways of improving yourself as a software developer. Being on the look out for readily available information and tools and being creative with the resources you do have access to can make a difference. As such, this pattern is incredibly helpful at showing that sometimes resources for learning can be right in front of you, you just weren’t creative enough to know it was there from the start.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

If my previous blog posts haven’t reflected it enough, I am definitely nervous to step into the professional software development field. This is likely mostly due to my case of imposter syndrome, where I think of myself as less capable or knowledgeable than I actually am. On another hand, though, I have also been overwhelmed by the thought of being behind other team members or colleagues in terms of knowledge and experience, even though everyone will, and should, be aware of this gap.

This week’s apprenticeship pattern, Expose Your Ignorance, further reassured me that learning new things and not necessarily knowing everything right away on the job is a normal occurrence. Everyone on the team is under pressure to submit work by a certain time, and when there is a “weaker link” who may not be on the same page as other team members, it can certainly cause some tension and perhaps anxiety for this team member. However, in order to best confront this issue, the team member should break down their walls hiding their ignorance toward the subject of the project, as well as let everyone else know about of how much they know and how much they still need to learn. It is suggested that one of the best ways to show this ignorance of any topic is to ask questions, as well as remain transparent when working with others so that the team member’s level of expertise is not misinterpreted. The apprentice should not only disclose this information, but also emphasize their willingness to learn and catch up with the rest of the team.

I already had a feeling that upon entering the workforce, senior developers and other colleagues would have some sort of understanding that I will not have as much experience as them, and that I will need to spend time catching up to what they know. This pattern was great to allow me to realize that I shouldn’t be afraid to let everyone know where my knowledge of our work stands, even if it requires further progress to strive towards everyone else’s level of understanding.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

          The “Sweep The Floor” pattern is described as a way be able find your place on a new team that is unsure of you. This pattern expresses how to find a way to earn your teams trust and contribute to their work without getting in their way. A good way to start is to volunteer to do simple tasks to show initiative and competence for small tasks to eventually work your way up to the big ones. An important fact to remember is to go for quality of work rather than quantity to ensure your teammates of how seriously you are taking this opportunity given by them. This may seem like a step back from all the studying and preparation you’ve done to get to the point, but you must also remember that now you are hired to be on this team. You must prove yourself before they can put any sort of trust in you and the best way to do that without causing any accidents are smaller tasks. This does not mean that you should let the team see you as the pack mule for meaningless tasks, but rather someone who can pick up the slack if needed.

         I found this pattern to be a great introduction to read before really starting out on a team. It allows an easier incorporation to the team dynamic and earn a teammates trust. It created a good sense of what to do and not to do so as to make sure that you are doing extra work for the good of the team while not becoming a pack mule. I want to start using these skills and think that they will definitely make working in a team easier. I think it will make the workload harder, but it seems to be a good trade off to earn the respect for other teammates. I agree with this pattern for that very reason because respect is a very big deal in teamwork. Every team member should prove their skills and respect for the good of the team. I want to continue this practice to make sure that my dedication and commitment to the team is seen to create a better bond with teammates.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Hello dear readers. Today we are going to talk about SOLID, the first five principles of the object oriented design.

S.O.L.I.D is an acronym for the first five object-oriented design principle. When these principles are combined together, it makes it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid easily refactor code and are also a part of the agile or adaptive software development. SOLID stands for:
S – Single responsibility principle
O – Open/Closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion principle

Single Responsibility Principle states that a class should only have one job, only one reason to change. The reason why we should use SRP is because it makes your software easier to implement and prevents unexpected side-effects of future changes. Another benefit of this principle is that classes and software components that have only one responsibility are much easier to understand, explain and implement than the ones that provide solution for everything.

Open/Closed Principle states that objects or entities should be open for extension but closed for modifications. Using this principle prevents situations in which a change to one of your classes also requires you to adapt all depending classes.

Liskov substitution principle states that every subclass/derived class should be substitute for their base/parent class. To achieve that, your subclasses need to follow the following rules: 1. Don’t implement any stricter validation rules on input parameters than implemented by the parent class. 2. Apply at the least the same rules to all output parameters as applied by the parent class.

Interface segregation principle states that a client should not be forces to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use. By following this principle, you will be able to prevent bloated interfaces that define methods for multiple responsibilities. You should avoid classes and interfaces with multiple responsibilities because they change often and make your software hard to maintain.

Dependency Inversion principle states that entities must depend on abstractions not on concretions. High-lever and low-lever modules also depend on the abstraction. This design principle does not just change the direction of the dependency, it also splits the dependency between the two levels by introducing an abstraction between them.

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

Good day, my dear reader! As I continue my education in Software Quality Assurance, I continue to read blogs and keep finding myself reading a blog about how to do one particular topic, or how to test in one specific method. Now those reads were all good and useful but one particular article caught my attention, “5 Reasons you are wasting your testing time“. Now I will admit, I did succumb to the very obviously clickbait title but, this was one title I am glad that I followed. In class, there is a lot to learn but some things are best learned on the job or get glanced over or forgotten in the classroom. This particular blog was about 5 ways to review your testing time and see where you are wasting yours.

The first way is not setting a clear goal. Establish a goal for the testing session and ensure that by the end of your testing session, the goal has been met. The second way is that you might not understand the value of the tested feature to the end user. This is saying that, while we are tasked to test a feature we should keep in mind if this feature actually is useful or helpful to the end user. The third way is that one doesn’t keep track of what was tested and your finding. This boils down to that you need to be able to adapt your tests as you are testing. Fourth is not consulting existing information to get testing insights. The last reason is refusing to do post-test reviews or feedback sessions.

The first thing that popped out to me is the consideration for the end user. This is definitely something that is not talked about in class. It’s something I keep running across and I hope I can keep it in mind as I head out into the job market. The end goal is to create a usable, program that an end user will actually use or purchase. The next thing that jumped out at me is that some testers, “…who say they consciously prefer not to see the previous test-runs or the bugs found in an area of the system in order to avoid any bias towards those areas during their current testing session.” I found this kind of silly that some people see testing a program like a clinical double-blind study. When I hear testing, I think of video game testers effectively ramming their heads against a particular part of a game until it breaks or they do. While I doubt I will ever have this mindset, it’s always good to know what to avoid. The last thing that caught me was that testing, “While at the same time it is an art, as you need to (almost instinctively) know how to adapt and change your testing based on actual stuff you find along the way.” This caught me off guard admittedly. Testing does seem dynamic to me but not in that sense of having to change the nature of a test mid-session. This is something that I will have to remember and try to put into practice out in the field.

Thus ends another blog and another week of discovery and learning. I can only wonder what I will learn next week and I am definitely excited to find out. Until then, have a good night folks!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.