Hi dear readers and welcome back to my blog. Today I am going to talk about another Pattern that I read from the book Apprenticeship Patterns. This blog post will be about familiar tools.

Once we start working or coding on our own we start to like and choose which tools we like and which ones we do not. It is just a matter of time for us to figure it out. Once we do though, its hard to switch. When I started coding, I was only learning tools that were recommended from our professors in school and as I was ‘scared’ to experiment I always choose not to switch even if I didn’t like it. Going to work and school at the same time was amazing as I was facing new tools in both environments and I was able to tell which ones I liked and found more useful and made me more productive. And as the book says, once you find your favorite tools, its hard to switch!!

This chapter talked about how all of us have our own favorite tools and we find it hard to switch even if the productivity sake is in risk. It would be our decision on weather to give up our tools or not but we have to face consequences. At the same time, just because a tool is great for you don’t mean it will  be great for someone else. Something that you might find easy, might be hard for someone else.

There is one example I would like to give for this Pattern. I started to use Eclipse on my second semester of Computer Science and I wasn’t crazy about it, but as we had just transited from BlueJ was very cool. Two semester later is when I started my job and over there the developers were using more advances IDEs and I was very excited to learn and get familiar. Eclipse went out of my list right when I learned about Illuminated Clouds. Very ‘smart’ IDE! However, Eclipse was still the only option in school and I was hating it and started to recommend to other people. Some of my friends found it very useful to use and some others already loved Eclipse for what it was.

Last but not least, I really liked the recommendation from the book that was suggesting to have developers create a list for all familiar tools and keep researching is the list was smaller than 5. All of us will probably change lots of jobs and lots of companies will have their tools, but its always good to have your own area of expertise.

Hope you guys found this blog useful…Stay tuned for the next Pattern from this cool book!

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

This method talks about how indulging in your own artistic nature isn’t always the best option even if you think the product would turn out better if you did it this way. If you are being paid to build something that will solve a problem, this method of Craft over Art explains you need to really consider the situation at hand. In this method, the situation that is discussed is that you believe that you are able to do something outstanding and fantastic that will impress your colleagues. In this situation, you are building something for a user. You shouldn’t be indulging in artistic expression. A lot of the times when we are handed with a task, we can sometimes think about the most outstanding ways to do something, rather than just to get the task done. This can go two ways. Doing something outstanding for a task can be great and have it’s benefits, but what will it cost the effectiveness of it? On the other hand, we can do the task at hand and that will be that. We won’t be able to put any personal expression in it, but is that a bad thing? Of course it isn’t a bad thing. This method seems to be very similar to function over form.

It is a matter of situational awareness. This is something I really enjoyed from this article. Make more straightforward choices and do not try to “sugar coat” solutions. As soon as you start making unfavorable trade offs in certain scenarios, the outcome will not always be as you like. in other words if you want a straightforward answer, you should provide a straight forward solution. Even though this isn’t always the case, I learned that you should always try your best to just try and perform the basic tasks first without adding anything extra or unique. Quality takes time, but having the correct operations in a product is what can make all the difference.

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.

Welcome back everybody to another Apprenticeship Patterns by Adewale Oshineye, Dave Hoover blog post. Today pattern is to learn how you fail which is about how we should gain knowledge from our failure. I agreed with this pattern context that failure is inevitable. I believe every successful person failed more than they succeed. I think that failure can be anything from programming to any day life activity. When reading this pattern, I realize that I have a lot of daily life fail goals. I will prioritize the fail and figure what is worth solving. I learned that it’s important to gain self-knowledge about the patterns, conditions, habits, and behaviors that lead me to fail. I disagree that we should consider cutting out losses and accept that there will be some things that we are not good at. I believe that some things that are out of our control should consider cutting loose but things that just requires more effort should always be work on to fix. I think it’s important to set unrealistic goals every day so you can push your boundaries. Even though I different thoughts on this patterning method to set realistic goals, I can envision that setting accomplishable goals can be more effective than setting unrealistic goals. This method will result in many failures but that will have many benefits as well when progressing to be a better version of yourself. After reading this pattern I am more aware of the way I now work. I feel the need to go over my failures and evaluate them. I found this pattern useful but very familiar. Even though this pattern was very brief, I still think it’s important for every programmer to review. This pattern made me realize that setting too many goals and I should be more focus on the worthy ones. I didn’t physical do the action exercise, but I don’t the main objective of the activity when reading it. I think the main idea of the action is that error is inevitable. All in all, this pattern learn how you fail is worth reading and change the way I work.

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

Draw you own map was the topic i picked for this week. I really enjoyed reading this pattern. It gives me the understanding of how to beat or overcome the huddles of learning new stuff and become very good at what we do or love.

From the reading, i also got to know, in order to be happy at your work place or your next career. You will have to pick a field you enjoy which most of my time i will be spending. The stories that Desi and Chris’s gave, give me the knowledge that planing your career at an early stage helps a lot. It makes you know what to expect and also what you want. Also from their stories, they could have prevented ending up in a a job they dislike by getting more info or doing more research about their next career or job. In case you did your research and landed to the job and later found out that it is not good for you. It is not late to change or learn new stuff. The pattern also gives ways on how to draw you own map. To me, it was very easy to understand and also felt it is the best way. The actions taken when drawing the map will definitely land you to the dream job you are looking for.

I really like this pattern(draw your own map. It has showed me a lot on how to really design my map in terms of my next career or job. it has also open my mind not just on my field of studies after graduating but also in life in general. I realized this technique that book showed, applies to everything. Not only for programmers or computer science students. I even made my own map which was really fun. I add four desirable jobs i will want to have for the next six years to come. On map diagram, about the desirable jobs, i included jobs no related to my field. Added fields like being a chef and nurse. Also added things i should be learning, whether things not related to my field or new programming languages.

From the blog CS@worcester – Site Title by Derek Odame 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.

Often times, as programmers, we will run into problems and will not know how to deal with these issues. Figuring out how to proceed is one of the most difficult things to do. What if the tool I am using doesn’t work? What if I am not fluent in a certain programming language to understand how to overcome a certain bug or fix a certain algorithm? These are all questions that concern us. The Dig Deeper method is very helpful in that it tells you to not just take everything that you learn for face value. Although tight deadlines and code maintenance may be daunting, you should always try your best in order to make sure that the code is clean. What we mean by this is that if you look up tutorials on how to do a certain task, those tutorials may have helped you solved the issue, but they could also have set you up for a lot of issues in the future. The tutorials may have cut corners or not complete things as efficiently as they should.

I really like this idea of Digging Deeper because we often try things sequentially that we find and just hope that the first or second method works. And if it does work we tend to just stick with it without even batting an eye at potential issues or large overhead that can carry. By completing tasks fully and really understanding problems inside and out, it is good to check multiple sources or tutorials. Code maintenance is huge aspect of live design programming. If you were to just look up random tutorials on how to do certain things for your code, you can get confused. You could look sup so many tutorials for each problem and eventually you won’t even be able to understand what does what action in your own code. And at that point, is it even yours? Being curious and making sure that you understand your code in a meaningful way will help you succeed and make further improvements to it. And the nice thing about this method, and many other methods, is that they don’t only apply to programming, but actually working with your team.

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.

When I was reading each of the introductions of the “Apprenticeship Patterns” book, the term “breakable toys” came up a couple of times. I wasn’t sure what the authors were trying to describe, so the Breakable Toys pattern was the next that I read. As it turns out, this pattern resonates deeply with me and my workstyle.

Breakable toys are essentially more private projects or spaces where practice is encouraged, without being concerned about the potential consequences of failing. For an apprentice who works in a high-stakes environment with no room for failure, this pattern is key to better understanding and learning about the tools used in their workplace. It removes the pressure of having to consistently be correct when developing software, which would be daunting not just for apprentices, but also for those with more experience. Breakable toys are great for anybody who simply wants a safe spot to work on projects away from their work environment.

Whenever I am writing code, or really doing anything in general, I am always nervous about failure. In conjunction with my previous post (which touches upon the apprenticeship pattern called Be the Worst), I also get intimidated when working with those with more experience, which in turn causes me to get worried about causing any failures when working with such individuals. For me, implementing a Breakable Toy would be great so that I could comfortably learn at my own pace, without fear of messing up in front of the development team and further affecting my ever-present impostor syndrome. I already have started various personal projects and courses, which I can now view as Breakable Toys of sorts.

Reading about this pattern didn’t really change the way I’m thinking about development and my apprenticeship process. Rather, it helped me realize that the kinds of activities that I’m already taking part in (like coding projects on my own or working my way through courses/textbooks outside of my schoolwork) are great steps that I should be taking in order to fine-tune my skills while also embracing any failures that may arise. By encountering these failures now, I can also better prepare for being a part of a development environment with less room for error.

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.

For this week, I have decided to read “Concrete Skills” pattern from the Apprentice Patterns by Adevele Oshineye and Dave Hoover. I have chosen this one since it is a good refresher for understanding that knowledge known is not the same. I believe this will help me in making so that I can be sure to give more demonstration than telling by just writing it out.

This pattern starts with the context of seeking out a role in a group of talented people that will provide better learning opportunities than currently. The problem is that the team, when asked, they can not risk of bringing someone that would not be able to contribute for the intended workload. There is also when thinking further, the possibility of not being able to do even the simplest task when asked. The solution to that problem is concrete skills, acquiring and maintaining them. With these skills, demonstrating and having them will increase the possibility of being trustworthy and be able to reach the goals. Eventually, there will be less dependent on these set of skills as the possibilities increase in being hired for the jobs intended.

From this pattern, what I found useful is the listing for concrete skills as an example to give the point of giving trust to the employer. As we try to give a good impression and trust for the likes of employers, we want to be sure that we at least have a clear understanding and demonstration of the basic things to do like JavaScript and the standard libraries by choice for computing jobs. Skills may require more thoughts to give an even better impression than intended, but it does answer questions to which the employer may ask. This pattern has changed my way of thinking in my profession. As I read the short pattern, it has become clear to me that I should not only directly say as intended but also if needed, demonstrate what I can do even if it is the basic thing. For this pattern overall, there is nothing I don’t disagree upon and this is because the pattern was able to give good perspectives of knowing what to do with this concept.

Based on the content of this pattern, I will say this is a simple but effective one. This pattern has showed good examples of the real-life scenarios. It allows me to be aware in the future of demonstrating than telling by just paper. For practice, I will show some technical work to give good impressions.

Link to the pattern: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02s04.html

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Practice as they say, makes one perfect. Practice is the act of rehearsing a behavior over and over for the purpose of improving on it to be perfect. From the readings, i notice the statement which says “Your grandmother may have told you that practice makes perfect. She was wrong. In fact, practice makes permanent. ” which i think was quoted by George Leonard. Actually, i think he is getting the whole thing wrong. Practice actually make you perfect and also makes your permanent. Whether you are learning the good thing or the bad thing, you will eventually be very good at it, leading to perfection.

I also learned by practicing, you do not have to do it alone. Just by being at work or under a master, you will be learning a lot. By learning you are practicing at the same time. You should also be making sure you are learning the best stuff, since what you are learning, can be come permanent. You don’t want to learn being good at something that will not profit you in the long run. That will be a waste of time and resources. In order ways while you are searching for a good place to work or a mentor, you should make sure you picked the right person(s).

Also while getting used to things, make sure you are learning other new skill. You don’t get stuck on one thing. You need to know more, and by doing that, you will have to learn new skill when ever you thing are okay with others. Pick harder stuff or projects to practice on. Always check you strength, if too easy move to harder ones.

This pattern has not caused me to change the way i viewed practicing. But it has showed me there are ways i can practice in an excellent way or a better way.  And also types of practicing i can take. Also to my understanding, practicing with peers is more an effective way to be better at your skills. I really enjoyed this pattern and i know it will help me now and very well in the future.

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.