The “Expose Your Ignorance” pattern is described as a way to come to terms with the fact that you won’t know everything in your field. Everything starts as a learning process when you enter a new team. It becomes easier as time goes on and creates a better environment when your team sees you making sufficient progress and growth. The pattern explains that creating a strong relationship with clients and colleagues causes them to grow more interested in your growth as a developer because of the increased efficiency you gain which in turn helps push development even further. Telling people the truth that you’re in the process of learning new skills may make them see you as an amateur but it is certainly better than giving them false promises of creating a finished product on time when you can’t quite deliver on it. This also brings up the point of asking questions, since questions can also show your ignorance but that shouldn’t matter as much since it all is a learning experience. You must ask questions if you plan on putting your pride aside and showing your team that you truly want to learn without taking any shortcuts.

          I found the importance of being honest with your team very useful to expose your skill set to them. The idea of letting your team exactly what you can and can’t do will help them better gauge what tasks they should start you off with to make the learning process easier. I enjoyed the fact that the book doesn’t tell you to shy away from asking questions. Questions can make you seem much more ignorant but the reason why you ask questions is to learn in the first place. This pattern expresses the importance of learning through honesty with your teammates which I will incorporate into my own experiences. The honesty aspect also will help with trust within the team as it shows that I’m not willing to hide anything from them. I overall enjoyed this pattern and agree with it completely. It repeated some very important aspects of teamwork and honesty that I will make sure to never forget.

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

          The “Create Feedback Loops” pattern is seen as a way to gain a better understanding of yourself without completely suffering from a blind sense of skill. The book continues on to say that self-assessment is limited to the abilities you have which makes it narrow minded if you don’t have many skills to start with. The best way to cope with this issue is to create a system where you can receive feedback or external data on your performance. It allows a more conscious take on your weak points as seen by other people which in turn will create a much more detailed self-assessment for yourself. The book then shows the importance of feedback in various environments such as job applications where applicants can be turned down, but this can become a learning experience as well. Understanding why one was turned down for a job also is a type of feedback that can show you different aspects of your character that you didn’t see. Finding a specific task to do is the hardest part because you must find something you can measure. Once this is done, compare how that task is affected by your work and understand how your actions are affecting it.

          I found the idea of creating different feedback loops with various people very useful and interesting. The idea of getting feedback from multiple people in multiple groups of your life could be very valuable information. I personally feel that there are aspects of work that meld into our personal lives and until someone else points them out, they seem second nature to us. This idea of taking others advice even when its not work related can cause interesting changes in how you tackle problems and view the situation. I found that listening to these valuable inputs is important but it’s just as important to understand which advice to follow as not all of them are good. I disagree with the idea that self-assessment is only limited to someone’s abilities. I think that even when you have little skill, you can accurately create an ideal image of what you want using facilities like the internet to expand on what you need to work on.

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

          The “Be The Worst” pattern is described as a way be able to keep learning after you begin to hit a roadblock and your rate of learning has plateaued. The book explains that the solution to this problem is to make sure you are around developers who are better than you and can help you identify your weaknesses by comparison. It removes the sense of comfort that builds up once an individual performs better and makes you recover faster from mistakes with more competent team members at your side. The learning process can become smoother through this pattern and allows the individual a better sense of understanding of their skills before and after joining the team. The goal is to not remain the weakest team member and to be constantly working hard to make sure that you can surpass your team members. This can lead to sudden risks of dragging the team down if you cannot catch up quickly enough and affect how you view yourself. The motivation of an individual is tested here as well how much stress one can endure and to push through for the eventual endgame.

          I found that this pattern is very relatable to me which in turn could be useful to apply into my daily life. I find it interesting how much of the situations the book brought up were so similar to problems I’ve faced in the past in terms of moving my skills up to the net level. I found that my learning had plateaued as well and didn’t really understand how to deal with it. The idea of removing my sense of comfort form my first language is thought-provoking because it seems to be very difficult for me to let go of my first language and move on to more difficult concepts. I have always loved learning Java, but this pattern as shown me to look past a single language and continue to grow with the industry. I still am hesitant to let go of my coding habits from Java but realize that I have to make this change immediately. I should surround myself with those that are better than me and try to survive in that environment to evolve my understanding of code at a faster rate. I agree with this pattern completely after fully understanding how it works and how to better my skills through my environment.

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

            The “Concrete Skills” pattern is described as a way be able solidify and maintain skills that would be helpful in a work environment. The book explains that many teams don’t really want to hire someone who won’t be able to help with the workload. There are too many situations where you would be a detriment with the lack of experience and skills. The books then goes on to talk about the possible solutions, one being to gain the ability to learn quickly. This can help show the team that you can be put to use in a working environment and not need to be supervised. It can also build a better relationship with the team by reassuring them that their efforts and time are not being wasted. Another strategy that is important is a great understanding of your first language since it can help you create a starting point within your first job. The book explains that communication and professionalism can be a strong driving force that accent your skills within your first language to better show off what you learned to employers.

            I found this pattern to be interesting in the sense that it relates to many new software developers looking for jobs. The through-provoking idea of being thrown into a software dev team that took a chance with a new developer is daunting to me. I find that if I was in that situation, I would need to work twice as hard to prove that I’m worth keeping on the team and that I have skills that can benefit everyone. This pattern shows me that concentrating on my programming skills and knowledge will be useful, but I will also need to have good communication skills as well to make sure that the team understands my viewpoints. I haven’t really thought about how important these communication skills and professional attitudes interlock with each other, but this pattern has shown me the importance of both. I agree with this pattern for the most part, however I found that it didn’t seem to give enough information about how someone could find their concrete skills in a team setting where many team members are already much better than you at your own language. Overall, I found this pattern interesting and very insightful.

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

          The book describes the “Learn How You Fail” pattern by talking about failure in general throughout a developer’s life. It explains that everyone fails at some point in their life and it shows the potential of growth. The blog continues to say that identifying where an individual specially fails can create better self-knowledge for their habits and behaviors. The main goal of this pattern is to then learn from these habits and behaviors to correct the ones that limit your potential. It brings to light the importance of creating an accurate self-assessment and awareness of weaknesses to find a realistic goal that can be accomplished. The book gives an example for coding where the programmer should try to use a text editor to implement a binary search in any language. Then write the tests for that search and run through it without a compiler manually to find any possible error you have made. You can compile the code after doing this to find any remaining errors that you may not have picked up.

          I found this pattern very interesting and informative in terms of self-understanding and creating reasonable goals. The way the pattern explains how habits and behaviors can become second nature which eventually leads to errors that we make unintendedly was very thought provoking. I enjoyed following the logic behind this and understanding how this can affect me in the long run as a developer if I don’t look for these errors now. This pattern has caused me to value my failures even more by teaching me more about learning from them. I always went with the logic that if I failed, I should simply not make that mistake again. However, this pattern showed me that instead of avoiding mistakes, I should naturally make them and learn from them in detail. This learning experience could provide me with deeper insight on how I will learn in the future and plan for my profession in a much easier light. I don’t disagree with the pattern at all, in fact, I thoroughly enjoyed every part of it. I especially enjoyed the example given using the text editor as a IDE to find mistakes in writing and compiling code.

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

https://qacomplete.com/resources/articles/test-scripts-test-cases-test-scenarios/

          I found a blog post this week that talked about Test Cases and the differences between Test cases and Test Scenarios. It starts by explaining Test Scripts and how they are the most detailed way to document testing. Test Scripts are usually a line to line description of actions within the code. It holds a lot of information on the software to relay data to the tester. It goes on to talk about how Test Cases are the second most detailed way of documenting testing work. Test Cases hold less information than Test Scripts because they only describe a specific function or idea to be tested. It allows more flexibility for the tester to find different inputs to test. It allows more detailed testing for testers that are familiar to the application for the program. The blog then introduces Test Scenarios that are known as the least detailed type of documentation. Test Scenarios hold a simple description of a function or intent a user might have when using the program. Like Test Cases, this allows more flexibility for the tester but also causes more areas that are likely to not be tested due to the undetermined scope of the problem.

          I chose this article because Test Cases were the most interesting subject when learning about the process of testing. I wanted to understand the difference between cases and scenarios which is what sparked my initial curiosity. I found that this blog was really interesting because it explains how testing can be structured based on the amount of information given. I enjoyed how the post explained the levels while also explaining how they benefit the tester through the expansive flexibility while also stating that this can lead to more grey areas of testing. I was able to grasp an understanding how these testing terms differ from each other and it expanded my visibility when looking at the testing process as a whole. The most interesting part of the blog post was the when it explained that testers can choose any of these terms to test programs depending on their knowledge of the product. This leads to the point where understanding the application of the product can also have great effects on how the tests are created. I found that there was a lack of diagrams within this post, but the information and definitions were easy to understand. I enjoyed this source very much as it easily explained the testing terms and how they differed from each other.

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