Most apprentices like me always face problems such as frustration and discouragement from peers and even their craftsmen sometimes. It is my dream as an apprentice to excel in my learning.  Some craftsmen will always intimidate their apprentices and it takes a brave and focus apprentice to stay on track. Sometimes, it is not just the craftsmen that will give you hard time. Being in a team that dictates your contribution can cause you a lot of damage in your learning. As a first comer, those who have been in the apprenticeship for years might have the mind set of you not knowing anything yet and will not value your contributions. Also, moment you have that feeling of fear and not able to speak out your ideas, you are on your way to failure.

However, this pattern has good information that can help me as an apprentice to figure out how to deal with most situations whiles learning.  One thing I have come to notice is that you cannot meet your desired expectation if you have no passion for what you are learning. Being happy or excited of what you learning or working on will actually enable you to put much effort into achieving your goals.

I am actually surprised of what makes a better team. Even though I am aware that a team of experience members can have problem due to everybody trying to be the leader, I usually think they will still have a better result. A team with varying levels of experience is the least I can think of being successful in its activities. I also think, believing in yourself that your contribution to a team will make a difference will enable you to openly speak out. Sometimes, I try to get as much as I could from my team members by listening to all they have to offer but very careful of what information I am taking from them because more often they are either misleading or conflicting with what I knew.

Again, I am not surprise craftsmen learn from their apprentices because a good apprentice will always search for knowledge outside his confined area and when his findings are openly embrace, craftsmen will benefit from it. Reading this pattern has impacted me with ideas that will help me focus on my apprenticeship journey. I will openly unleash my enthusiasm and would never allow others or circumstances around me to dictates what I can offer to my team.

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

I thought this section of Apprenticeship Patterns presented a fascinating take on how newcomers might fit in with their more experienced counter parts when entering the professional world of computer science. The authors describe the role an “apprentice” might want to take when working in a team of seasoned computer scientists. They explain that it is common place for newcomers to “fly under the radar” and not speak their ideas due to lack confidence in their ability to be a contributing team member. They point out that while every team may differ, teams typically benefit from having team members of varying skill levels, even “apprentices.” The authors also cite a study involving aircraft carrier crews that showed that it is healthier for teams to consist of people with different degrees of skill and experience and found that newcomers played an integral role in the team dynamic. Finally, the authors propose that newcomers should in fact “unleash their enthusiasm” in hopes that their excitement will rub off on other team members as well as keep other team members on their toes through asking many questions on why things are the way they are as well as presenting fresh ideas.

I honestly found this particular pattern to be extremely relatable as I am currently a newcomer in a security team that is made of individuals who have varying degrees of skill level, experience, and expertise.  When I first started, I admit that I was a little intimidated by all the tools that were being used not to mention all the acronyms being thrown around in meetings that I had never heard of before. However, I feel like that feeling of being overwhelmed pushed me to want to learn more about security and obtain the same kind of knowledge possessed by my coworkers while at the same time applying the knowledge I have acquired throughout the course of my college career. I also feel like I really lucked out because of the willingness of each of my team members to answer my questions and give me advise. After reading this pattern I think I will ask questions and speak up more confidently at work because now I know that it is important to bring a fresh perspective to a team.

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

This pattern seeks to solve the problem of skill gaps that are making daily work more challenging.  The authors propose that software apprentices suffering from this issue attempt to actively learn the missing pieces.  This could take different forms — they suggest reading tutorials/FAQs, constructing small low-stakes projects, and/or involving other people that are either experts in the area or trying to learn the same thing.  They also suggest keeping a list of these skill gap areas, and crossing them off as they’re sufficiently learned; this goes hand-in-hand with adding to the list as your learning exposes additional gaps.

This approach to learning really resonates with me.  My preference is to actively seek out knowledge, and I tend to learn best through hands-on practice.  I’ve already used a less formalized version of this when I taught myself Python: find a skill (in this case, a programming language) that I would like to learn and then give myself a project to work on that forces me to learn and use it.  There are three major additions (on top of the formalization) that I can take away from this pattern:

1. Involve other people, whether they are experts or fellow learners.
2. Don’t overuse this pattern to the point where it causes problems for others; I only have so much time.
3. Balance learning with introspection.

The first point leads to the creation of a learning community, and extends both the resources and benefits of learning.  I know that I have a tendency to want to do everything myself, and while independence isn’t bad it’s also important to not always be reinventing the wheel.  I also enjoy sharing my knowledge, and it makes sense for me to seek that out in a more mutual way.

The second point is also something I run into often, and partially extends from the first.  I really like to build things from scratch and see how they’re made.  However, that tendency can also lead to excessive use of time and energy for what should be a simpler project, or the preference for my own solution over another (quite possibly better) one that’s already been written and vetted.

The third point encourages me to set up a cycle of learning and introspection; crossing items off of the list and then adding more to the bottom.

While actual checklists are not a tool I particularly enjoy using, this pattern has leaned me towards perhaps keeping one (and actually updating it).  That, I think, is where I’ve found the most value in Confront Your Ignorance.

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

You can find more information about A Different Road pattern here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s08.html

This passage is very quick and to the point. The authors emphasize that you should continue to follow your own map. Even if this new map brings you into an adventure you have never thought about doing. The authors ask just one thing, bring all of the knowledge and processes you’ve learned with you. Being a software apprentice means that you can look at problems from different perspective and use the tools and knowledge around you to excel and progress further. This way of thinking is not only useful in software development, but everywhere else too.

My favorite part about this pattern is that the authors understand that sometimes life can be strange. I enjoyed the example “…Ivan Moore, Ade’s mentor since ThoughtWorks, he described how he went off to a Greek island for six months to become a windsurfing instructor after his first IT job.” (Oshineye, Hoover). I liked this because it was so obscure. Who stops developing software to teach windsurfing? Well that’s the point. Everyone has different values in rewards. Regardless of what you want, someone else may want something entirely different. Maybe that windsurfing job paid HALF as much, but maybe money wasn’t important to Ivan. Instead he wanted to reap the rewards from enjoying life on a Greek island, the experience and the fun. These rewards could have been more valuable to him and you can’t tell him he is wrong.

The authors also tell you that leaving the field for some time could be risky as most conventional software companies see the break as a suspicious gap in your career. However, the authors also let you know that this- shouldn’t be the case. New experiences can help widen the perspective of one’s view. Leading to better understanding, communication, and team work.

At the end of the pattern the authors give you an action. All this is, is a suggestion on what to do if you are experiencing something like this problem in the pattern. The authors ask you to “write down some of the other jobs you think you would enjoy doing. Find people who are doing those jobs and loving it. Ask them what they love about it and compare that to the things you love about software development.” (Oshineye, Hoover)

At the end of the day, you should really be doing what you love and what rewards you, the best way you see fit.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Problem: You feel your job depends on you delivering a solution written in a specific programming language and of the same standard of quality as your teammates. Alternatively, obtaining a job in the first place depends on your proficiency in a specific programming language.

Solution: The text suggests picking a language and becoming fluent in it, as it will be the main language you will be using for the next few years to solve problems. It’s a difficult choice to make, especially when looking for jobs that may been looking for specific skills and languages. It’s “important to carefully weigh the options, as it is the foundation upon which your early career will be built.” One good way to gain experience and become fluent in a language is to actually have a real problem to solve, and to “seek out opportunities to create feedback.” Becoming fluent in a language allows you to start working more on test-driven development, allowing you to check your assumptions and aiding development of new languages.

This pattern has good advice, and it’s not the first time I’ve heard someone suggest working on one language and perfecting it instead of trying to learn multiple languages at the same time and expect to be fluent in each one. An interesting tip from the text was building a toy application in the language you’re trying to pursue a job with, one that your prospective employer would be able to access. Good learning experiences come from solving real problems, school gives you a good foundation to build upon and learn from the problems you solve in your professional career. Working in the field and running into real problems, the ability to work with other people and learn from them is a big part of gaining skill. I think Java would be a practical choice to become fluent in as it’s a high demand language that receives a lot of bad press but it running on 3 billion devices. The book also mentioned the community behind these languages and all the resources you have at your disposal. They suggest taking advantage of the support network you have and attending local meetings related to that language.

The post Your First Language appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

For this week, I chose a blog which talks about the future of software testing. Although these are just predictions by Ryan Yackel who is a senior sales engineer at QA symphony, they really seem plausible and get you thinking about where software testing is going to be in the next decade or so.

Ryan talks about how Everything will be blurry in the beginning and gets clearer after. what he means by that is the fact that agile software development methodologies are now becoming the standard and that will lead to a lot confusion and misconceptions. Because everyone is considered tester in a agile environment which is not true in a lot of cases, this really leaves testers questioning the severity of their role.  Agile methodologies’ popularity is increases among companies and they will soon have a better understanding and mastery of these agile techniques. Once this occurs, the role of a tester in a agile team will become much clearer. This leads to his next prediction.

Software testers expectation is on the rise and Ryan mentions that the expectation will be even greater in the future. Now, software testers need to expand their horizons and embrace new enterprise software testing tools and strategies. Just being knowledgeable about testing software is no longer sufficient. Software testers needs to be knowledgeable about software development, code functions, business logic, and technical competency. Testers a now playing an assertive role in guiding software quality assurance and development broadly.  As a tester, if you fail to adapt to these new higher level expectation, you will have a hard time making it through.

Ryan also talks about how the use of automated testing will increase significantly. It will be difficult for companies to maintain efficiency due to fast growing data in software development. Therefore, many companies will rely on automation in order to maximized their level of productivity. Ryan predicts that automation will become the default method of testing and all the challenges that holds automation testing from being the best way to test software will soon be refined.

From the blog CS@Worcester – Adestin by adestinyblog and used with permission of the author. All other rights reserved by the author.

This week I decided to read a blog post for my blog entry. The blog post I read is titles “Writing Clean Code” by Jason McCreary. Before finding this blog post, I’ve had a general and basic idea about coding and how it should be written, but I haven’t understood in great detail how to properly write clean code. The reason I chose this blog is to learn and be able to use the clean coding techniques on my future projects so it will be easier for other people read.

Clean code is extremely important in becoming a strong software engineer and when working in a team having clean code is a must so your teammates can understand your code. The blog opens up by saying that in more or less all software engineering jobs you will be working with a new code base at one point or another and that inconsistency is a big fundamental problem when working with different code bases. The author ends the blog by saying “In the end, coding is writing” and as a developer our responsibility is to maintain a consistently so it will make our code easy to follow when being looked over.

One major takeaway from this blog that I will apply immediately to my next project is using clearer names. Before reading this blog if I wouldn’t put much effort into naming things in my project but I learned that applying clear names not only improves readability, but boosts the context making the intent of the code easier to read. If I am to use clear names it will help the reader understand more quickly.

My goal is to become a software engineer and in the CS program sometimes it is hard for me to write clean code because I am focusing on other parts of the assignment or don’t have everything labeled to where my audience can understand. This article has given me ways to write clean, effective code in the future and I hope it can do the same for you.

Source: https://dev.to/gonedark/writing-clean-code

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