The Retreat into Competence pattern describes what you should do when you feel overwhelmed with how little you know. Every apprentice will eventually feel ignorant or incompetent compared to the craftsmen they will meet. This should not be a reason to worry as it is a normal and inevitable phenomenon. However, when it happens you should retreat briefly into your competence. What this means is to work on something that you already know very well in order to regain some confidence and realize how much you’ve learned since you began your journey. This pattern is relevant for people who are struggling or stretched beyond their ability. If you find yourself in this position, you may need to take a step back before you can continue going forward. However, it is important to realize that this pattern is only a short-term fix so that you don’t surrender to the comfort of working only on things that you know very well.

I enjoyed reading this pattern and found it to be useful because it is applicable to everybody at one point or another. Reading this pattern reminded me of impostor syndrome, which is when somebody persistently feels like a fraud despite evidence of their competence. I think this is something that a lot of computer science students feel since there is so much information to learn and the technology and tools we use are always changing. I think that this pattern is great advice for someone who has a case of impostor syndrome or simply feels overwhelmed by their work. Taking a step back and working on something that you’re comfortable with will allow you to clear your head and regain your composure. It is important to remind yourself from time to time how much you actually know and realize that many things you do easily now once seemed impossibly complicated. Retreating into your competence will help you spring forward when you go back to new challenges. I’m glad that I read this pattern as this advice will definitely help whenever I feel lost or overwhelmed in the future. I now know that in situations like that it will help to retreat into competence for a little while.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

For this week’s blog I have read the “Learn How You Fail” article of the textbook. The context of this chapter is failure is inevitable, how will I learn from my failures to prevent them in the future? The context set up for the problem is that we learn from our successes and we are successful because of our successes but we also still suffer from our weaknesses and our weaknesses lead to failures.  This rings true with me as I understand that I do not know everything there is to know about software and software development. How I view this is to learn from my failures and learn how to prevent them in the future. I understand that I will fail eventually, as I do not know everything. I understand that I also will learn from the mistakes I have made and the failures I have encountered and I will lean how to prevent them in the future so that I will never have to see the same failure twice in my career. The solution that the textbook is proposing for this is try to identify your failures or areas that your fail before you do fail. Being a self preventative at failing will help myself not encounter failure as much in my future. One point that I really enjoyed was learn what trips you up and become conscious of it. This is a great way to prevent failure because if you encounter or something or know you will soon encounter something that often tends to get you to trip up, hopefully if you realize that is coming down the line you will have ample time to correct the issue before it becomes an actual issue that will result in failure. If you are able to avoid this failure, then you can consider yourself successful. And as we learned earlier, we learn from our successes and we are successful because of them. When we avoid failure we can consider it a success. We need to understand that we cannot become crippled or frustrated by our fear of failure. We have to understand where we fail and learn how to stop ourselves from failure instead of fearing it until it strikes. I have learned a lot from this article and I hope to avoid failure in the future by using the skills I have learned here.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

       The “Read Constantly” pattern is described as a way to create a strong base of knowledge and an even better understanding of the industry around you. There seems to be such a vast amount of information out there today that it seems very intimidating to even fathom where you should start. Reading is the best way to start learning more about the industry and more abstract yet fundamental concepts. The idea of reading everyday may seem like a lot of work at first but the key is to completely immerse yourself into the context of the text. Find new ways to apply what you learn to what you are working on and familiarize yourself with patterns before they become more popular and widespread. Another good way to read is to section parts of the book into manageable pieces to organize your learning experience such that it flows easier reading from one chapter to another. The book also talks about momentum when finishing books by allowing a brief but not long period of absence from reading. Find your next book and move onto it as fast as you can without creating a disturbance in your work life.

            This pattern was interesting because it showed me a way to read without making it too overwhelming. Every book I find on coding seems to become very overwhelming with the amount of content inside. The content itself becomes boring when reading for too long, it begins to sound repetitive which leads to a lack of interest. I found the tactic of breaking these large amounts of reading into smaller portions a great idea. I’ve been currently applying this tactic with great results as I can retain the smaller amounts of information better and this allows me to keep a more vested interest in the book. I also found that focusing on the portions of the book that interest you can make it easier to read. Focusing on ideas and aspects that you want to learn more than the rest makes the reading go by much faster. I agree with this pattern because of the amount of information that is available at all times to us. It’s very important to use our resources to the best benefit we can take from them. Books and online readings are everywhere these days and it makes information much easier to obtain, so to sharpen your skills you must broaden your skill set as well.

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

During the first sprint, our goal was to get everyone set up with the development environment so that we could all build the AMPATH project and get to work as soon as we were given user stories/had tasks. I believe of the time of the last blog post, we still had to finish getting one or two of my teammates set up, but that was resolved rather quickly. After that, it was learning testing in Angular while playing the waiting game for AMPATH’s team to get in touch.

And well, wait we did. That was no fault of AMPATH’s, though. They’re a rather small development team with a big project. They’ve got their work cut out for them and they’re seemingly very busy.

Unfortunately, with how busy they were, we didn’t get any new tasks to work on at all this past sprint. What was nice was that we got plenty of time to familiarize ourselves with angular and testing. Reviewing testing was important because, for the upcoming tasks we got, we’re trying to figure out whether or not we’re going to be using mocking or a real database with random values for our “back-end” data. If we go with mocking as AMPATH has suggested to us, then our time spent learning testing with Angular over this sprint will be put to good use. I’m also pretty thankful for my Software Quality Assurance and Testing course that I took last semester, because that went in depth about a lot of these same topics.

Overall, Sprint 2 was fair uneventful. However I feel as though my team got more accustomed to working with one another and got a bit more comfortable with each other, too. So for those reasons, I think that it was a positive sprint. I’m excited for the next few weeks of Sprint 3 so we can start working on some coding!

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

This is blog post on chapter five “Perpetual Learning”, the book build on software development is composed of two primary activities: learning and communication. “The Perpetual Learning patterns are applicable for your entire career, but with the apprentice’s emphasis on learning”. For new developer, learning is the most important part. In this “Expand Your Bandwidth” pattern, they are talking the most important process for most of developer. Expand your learning, in this continuous new information business. We will never stop learning, so learn how to learn without being so overwhelmed is extremely important. I think this is important skill to have, although everyone learns differently.

In software developer, there is no “know all” skill. We are learning as we go, we learned the basic skill at school and more specific as doing project/job. So how to learn while working. The book suggest that we develop expanding our ability to take in new information. “The discipline and techniques necessary to efficiently absorb new information, as well as to understand it, retain it, and apply it” and this is what really think is the CSS learning model. We must be active learner; we use the tools we must keep up with news/ learn new skills/ communicate with others. They also suggest that we understand when to Expand You Bandwidth. This is different to everyone, but if you test out your methods and see which work best for you.

I am agreed with most of the points of this pattern. Computer science is active learning, there are million thing we could learn. We need to know to pick and learn what we interesting and benefit to our career. I heard on a tech podcast, one way to learn is to try use technology for a week. After that move to different tech and see which one is for you.

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

The Deep End describes the situation where you feel like your skills have plateaued and you are having difficulty finding ways to improve. As it sounds, The Deep End is a pattern that encourages you to “dive in” to the deep end. That is, to take challenges that you know you could fail, knowing at least that you can learn form your failures and improve yourself as a result. It is not about taking uncalculated risks or lying to get opportunities, it’s more about taking on things that you aren’t certain you could do, but have the means to do so.

The Deep End is a pretty intuitive pattern. When you feel like you aren’t improving, push yourself in ways you haven’t before and turn it around. However, it can be very intimidating in practice to take on projects that you aren’t certain you can complete, especially if you think you have to worry about potential consequences. Although learning from failure is a very effective way of learning, it can also be very costly, and that definitely gives me anxiety.

That being said, it is important to take risks and leaps in my life and my career. It is the only way I am going to improve myself and get what I want, and being too nervous to take chances and opportunities as they come my way certainly wont help. I will make note of the lessons taught by this pattern and try to take more risks in the future. I think it will especially help me with my directed study this semester, which has begun to push me into learning many new languages and concepts all at once.

The Deep End is a cool pattern, and the it makes sense practically. Most people are definitely aware of the idea of taking on harder tasks to sharpen their skills. Most people want to improve, but it can be scary to tackle hard challenges and face the unknown. However, getting over that anxiety is crucial to becoming a smarter, more well-rounded individual. Life isn’t easy, and you need to be ready to solve hard problems at any moment.

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.

We’re computer science seniors at Worcester State University so that means we should be able to write a full fledged technical documentation for the program we have written am I correct? Yes and no. We were taught the importance of writing documentation and very lightly touched upon what should be included in documentation but after reading ‘Software Documentation Types and Best Practices’ I learned there are actually different types of documentations for different projects.

The image below shows a general guideline for the steps to be taken when it comes to writing a project documentation.

We know that the main goal of effective documentation is to ensure that developers and stakeholders are headed in the same direction to accomplish the objectives of the project. The image below is a breakdown of the two main categories of software documentation:

The author then goes on and describes the different types of documentation:

System documentation represents documents that describe the system itself and its parts. It includes requirements documents, design decisions, architecture descriptions, program source code, and help guides.

User documentation covers manuals that are mainly prepared for end-users of the product and system administrators. User documentation includes tutorials, user guides, troubleshooting manuals, installation, and reference manuals.

Process documentation represents all documents produced during development and maintenance that describe… well, process. The common examples of process-related documents are standards, project documentation, such as project plans, test schedules, reports, meeting notes, or even business correspondence.

All in all I learned that there is not one special or main way to write documentation but there are actually many.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

CS 443 has taught me many things: how to test code, the different ways to test code, collaboration among peers, what is possible/not possible in Java, mockito, the list goes on. What it has not taught me is how code is actually tested in the field professionally; what should I expect to do or know if I were to shift towards the QA Engineer path?

‘A Day in the Life of a QA Engineer’ by AJ Larson talks about what he does in a professional setting and I compared it to the daily tasks we performed in class and it seems it is not completely opposite. He starts off by comparing software developers to QA engineers and stating that it is not too different; some companies even combine the two into one where you are a dev and a tester. He talks about how the team communicates; telling each other where they are in the project, what their plan is and if they have been encountering any problems. I guess in a way we have been doing that in class.

Onto the more important part of this blog is where he talks about testing ‘stuff’. He spends his time running manual tests and when he encounters a failed test how he goes about it. I learned that communication is key in both school and professional work environment; pretty much anywhere there is teamwork there must be communication.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.