For the fifth week’s reading, I chose to read the pattern, Be the Worst. It is about facing a problem where your rate of learning has plateaued. As such, a solution is needed and is presented as instead of being in a team where you are at the top. You will have to find a team where you can be at the very bottom. The objective is to work your way up from the bottom, and from that you should be able to learn from those who are better than you. By actively trying to become better than what you were before, you allow yourself to continuously improve. However, there are risks of placing yourself at the lowest. The first is that you could be a negative impact to the team which would mean that you aren’t contributing as much as you should. Second, you might find yourself losing motivation when things do not pan out the way you thought it would. The action provided in this pattern is to rank teams by skill level and find a team that would allow you to work your way up.

What I found interesting about this pattern is that there is no easy way of solving this problem. You have to be willing to improve, willing to learn, and willing to drop your comfortable position to continue chasing the top. After allowing yourself to do that, you need to continue having the motivation and enthusiasm to improve yourself in a team that you know is way more knowledgeable than yourself.

This pattern has made me think about the intended profession in a way that everything will not remain the same forever. As time passes, teams will become more knowledgeable, but every individual will learn at a different pace. If you happen to be a person that progresses faster and becomes better than the team much quicker. You will eventually come to the realization that your learning has plateaued. By planning your road map in conjunction with this pattern, you have a chance of continuing your journey to become a master if that is what you wish. This is what I learned from this pattern.

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.

For the fourth week’s reading, I chose to read the pattern, Breakable Toys. This pattern focused on the problem where you are introduced into an environment that doesn’t allow you to fail. Even though everyone knows that you are learning from your failures is the best form of learning. There solution is that you create something similar or a private environment where you can create and work around projects that are similar but not replicas of the projects where you work. The goal is to learn from failing in similar projects where you can learn how to work around them and possibly apply concepts learned in the future. An action provided for this pattern is to build a simple wiki while maintaining quality. In effect, you should be able to keep implementing more features by learning and applying them. Concluding this would be, don’t let work constraints prevent you from learning for yourself and take control of what you can learn and apply.

What I found interesting about this pattern would be their example of breakable toys. Which is to re-create known tools to give yourself a deeper understanding about the tool and why it came to be that way. Examples of these are games like Tetris, tic-tac-toe, or other simple software. By being able to successfully recreate such games and software, you can get a feel for the thought process and problems that the first creators may have come across and face long ago. Enabling yourself to have time, experiment, fail, and try again is essential in learning. Another would be the wiki solution, as you may learn much more than expected over a longer period of time.

This pattern has reinforced my current thoughts about my intended profession. I believe that there will be many different environments to face in the future. Some may be welcoming, and some may not be so welcoming. By learning about how to deal with a situation such as this one where failure is not allowed. Being able to adapt quickly and create a workable solution is important in progressing as a person and in the field of software development.

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.

For the third week’s reading, I chose to read the pattern, Unleash Your Enthusiasm. This pattern is about handling the excitement of being a software developer once you join a team. Joining a team brings responsibilities such as considering how the team functions. The enthusiasm you bring into the team could be accepted or rejected. Depending on what happens, you are required to handle it correctly. For example, being overly enthusiastic could potentially backfire such as making a bad impression in front of a well-established team that is currently low on morale. For teams open to excitement, you can be yourself, as they are accepting of possible ideas and creativity you could bring. This type of environment allows yourself to throw ideas with very little to lose as well. By being a newcomer, it’s said that you are in a unique position of having a fresh perspective for the team. As with any team, improvements and suggestions can be made by all members, as such, your opinion also matters.

What I found interesting about this pattern is the excerpt about a study on the collective mind of aircraft carrier crews. The conclusion of the research was that its healthier for a team to having people of all levels of experience. This is true in a sense that if you have a team of all veterans, it’s very easy to be in a mindset where you could do no wrong. While incorporating members that have less experience, the veterans would benefit from reviewing basic information that they could potentially overlook or forget. As such, new comers do have a unique role as stated earlier in the pattern. Another interesting part of this pattern would be the action it proposes. It seems to be assessing the thought process in rejecting an idea you have before getting opinions from those you are suggesting it to. By surfacing the scrapped idea and presenting it to said person/group, the individual could learn more about their idea and maybe more. Taking risks is apart of life and sometimes proposing ideas aren’t as risky if you benefit from learning from your peers.

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.

For the second week of reading, I chose to read the pattern, A Different Road. This is a continuation off of Draw Your Own Map and discusses an issue. The issue is when you have followed your own path as a software developer and hit a road block. This road block is not about whether or not you could become better and rather that of a change in interest. It details the possible outcome of leaving the industry to pursue another interest and what could happen upon returning. There is a chance that the gap from working in different industries could work against you in the end. It is said that some organizations will deem the inactivity from the field as suspicious and will question your return. The risk is big, but it is still important to follow your road map where ever it leads.

What I found useful about this pattern is that it encourages others to follow their hearts or road map that led them up to the decision where they might be leaving the profession. Everyone only has one life, and usually the saying is to do what makes yourself happy. Sometimes, people need a change of pace and it’s important to recognize that. However, I am not surprised that some organizations will question your absence from the profession if you chose to leave for a while. I’m sure many of us who chose to study computer science has realized the type of field we are going to throw ourselves into. Another interesting part of this pattern is about the work experience between two different jobs can sometimes be used effectively. Depending on the context of course, one experience in a separate field may be used to fix or provide a solution to a problem in a different field. This also goes back to the organizations who might disregard any experiences that an individual has that isn’t related to the experience needed to fill the desired position. I feel that the only choice after leaving the long road for a while is to work twice as hard to get back in. Lastly, I do believe there are probably plenty of ways to accomplish that and it’s not a lost cause overall.

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.

For the first week of apprenticeship pattern readings, I chose to read Draw Your Own Map. This pattern focuses on the career path that you chose for yourself based on your future or current employer. It tells a tale of how employers can only lead to a limited amount of career opportunities from your current job status. To work through this system, it is necessary to create a plan or road map for your future endeavors after moving forward from where you currently are. By lining up paths that can be available to you based on your current desires, knowledge, and expertise. It will be easier to find yourself in work that suits yourself the best instead of settling for less. These roadmaps should easily be updated to your current situation whenever you see fit. The overall idea behind this is that no one will be able to tell you how your career will end up, everything is up to you.

What I found interesting were the two short stories provided near the bottom of the pattern which clearly showed how reality will present itself. By providing evidence of how some apprentices feel about their current work experience, realizing what they actually wanted, and making a rather small but big step towards their dream career path is inspiring. It also goes to show that not all companies will have their interests aligned with their employees. Also, the action listed at the bottom is helpful to show that. By mapping out from each job choice and their potential benefits and paths that could open or give an overview of how you will end up later on. By not limiting your choices and have a willingness to redo the diagram until you are satisfied with the end result. There is a big possibility you will find happiness at the very end. Otherwise,  I enjoyed the fact that this pattern is straightforward with budding apprentices like myself. As quoted, “Understand that it’s not up to your employer, your career counselor, or your professors to give you a hand up.” Every decision lies in us, by having a plan, you can reduce the amount of roadblocks you will hit along the way and make more informed choices in your career path.

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.

Source: https://www.guru99.com/fuzz-testing.html

This week’s reading is on fuzz testing. It is defined as an automated technique that is used to uncover errors that will most likely missed by manual inputs. As it is a black-box testing technique, it deals with the execution itself rather than going through the source code. Due to the way the technique works, it will be able to find serious defects and security loopholes in the software it is tested. It’s also stated that the technique is one of the most common method for hackers to find vulnerability in systems. The general steps to fuzz testing is identifying inputs, generating fuzzed data, executing tests using that data into the system, and logging all of its findings to be reviewed. Typical bugs detected by fuzz testing is assertion failures, memory leaks, invalid input, and correctness bugs. It’s very simple but will improve the quality of the software and improve security overall.

I found it interesting that the article mentions that it is a common method for hackers to use fuzzing in order to gain access into a system. However, I am not surprised that they do considering its overarching objective. Knowing that the technique is used by testers to find vulnerabilities in software, it doesn’t hurt for hackers to see if the common vulnerabilities have been accounted for through testing. Another interesting tidbit would be about correctness bugs, as I do not remember being able to test for corrupted databases, poor search results, and etc. using other techniques available. I also agree that fuzz testing alone will not solve all of the security issues. As it will account for invalid inputs, correctness bugs, memory leaks, and assertion failures. There are probably other methods available that are specialized towards handling complex security threats. In other words, fuzz testing will only help identify common vulnerabilities and sometimes help against major ones. Knowing that this method exists for black-box testing, as with other methods available through white-box testing. By using it in conjunction with other effective methods will create a product that is of high quality, secure, and cost-effective. Its similarity coincides mutation testing as it ensures the software is robust. In conclusion, it is fuzz testing is useful for showing presence of bugs in an application but will not guarantee full coverage.

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.