Hi dear readers. Welcome back/all to my next blog post about the next Pattern. The next Pattern I am going to write today is about ‘Reading List’. Yep you heard it right! Reading List! Just because you are a developer doesn’t mean that you got no more reading to do.
This Pattern in the book talks about how to start with a reading list and how to keep up with it. The authors make very good points when they say that its hard to even start a reading list as you might not be sure what to read first. I like how one of the recommendations is to ask your mentor/professor. They would be the people who know your development level better than anyone and will definitely be a great help. Another point to keep in mind is that the initial Reading List you have created might (probably will) change after you have finished one of them. Having a Reading List is great because it also makes you reflect about what you read previously.
As mentioned in the book, we should always think and analyze about the book we just read and try to figure out on our own on what should be the next book to read. Computer Science is one of these field that new things will always keep coming up and what better than books will be describing these new innovations. Indeed these new books should be on top of the list.
I believe that there will be cases where you/me as a reader will be disappointed on one or more books. It’s not right that just because one book was not good enough, we should stop reading other books. I think that when you don’t find a book interesting or good enough, it’s a good sign as you are thinking about the book content. This will give you a better understanding on what you would like to read next and what is your favorite area. For example, for my reading lots of books about programming languages wouldn’t be too much interesting. On the other hand there are people who love reading each and every book about programming languages and this is because they’re passionate about it.
I would recommend to just start somewhere, and then you will be able to figure out on what to jump on next.
From the blog CS@Worcester – Danja's Blog by danja9 and used with permission of the author. All other rights reserved by the author.
On my readings on the patterns, “share what you learn”. By teaching what you already know about your profession, you’ll learn more, make new connections with people, and find new opportunities. And by doing that you will may find it very fun.
From the reading, to my understanding, another reason you shouldn’t wait to start sharing with others is that it will help you learn. Research has shown that when we explain something to other people, we come to understand it better ourselves. The process of teaching or sharing what we have learned to others, helps us recognize gaps in our own understanding and better organize information in our minds.
Also one thing i notice about sharing what you learn with others will give your talents more exposure, thus giving the people you interact with the opportunity to identify you as a valuable expert. Helping others can help you build your reputation. Also sharing what you learn can be a great tool for everyone. All you need to do is to be permanently connected to the hot business topics and offer your expertise every time you can. When people are open to prove their value through their competence, it’s easier to notice the ones likely to organize people and to take initiative.
Let’s take for instance, you are in the team, by sharing what you learn or known and talking about certain decisions and procedures, the new guys or juniors could easily acquire new sets of skills. Create an environment where everybody is encouraged to ask questions, and help professionals in all your locations and job positions stay updated with the latest information in their field. Also by sharing what you learn, increases the productivity of your team. You can work faster and smarter, as you get easier access to the internal resources and expertise within your organization. Projects don’t get delayed, people swimmingly get the information they need in order to do their jobs and your business fills the bill.
I really enjoyed reading the pattern because i got the some main importance of sharing, strategic ways of sharing and things that i do not have to do.
From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.
Hi everyone and welcome to another CS 448 Software Development Capstone blog. Today blog topic is about one of the individual apprenticeship patterns which happen to record what you learn. I wanted to read more about this pattern because I can relate. Ever since last semester I been writing many blogs and didn’t fully understand why I was posting them. At first, I thought this method of recording what I learn was to help us research more information and writing them as blogs would help us understand the material better. After reading this, I realize that it’s just more than blogging once per week. I understand that recording our journey helps keep vital resources, makes our journey explicit, and can be helpful to many others. I feel like after reading this individual apprenticeship pattern I will change the way I work because all this time I was blogging, I didn’t really blog for purpose and just blog because it was assigned so I think I will be more efficient when I blog now. I also picked up a new idea from reading this pattern which is to have two journal that is private and public. I can use the public for sharing what I have learned and gaining feedback and the private one for me, to be honest with my status in programming. I do agree that it best to have both because of the perks that each offer. I like when the record what you learn pattern state that Dave was constantly posting his journey for years and eventually, he had tons of resources that he then later uses later in his career. The reason why I like this statement is that it makes me more motivated when posting these blog assignments because I know that eventually, it will come in handy one day in my career. All in all, I felt like this individual apprenticeship pattern, record what you learn is very informative. I learned that every apprentice should keep a journal for their journey and try to write every day as one day it will help others and even help themselves.
From the blog CS@Worcester – Phan's CS by phancs and used with permission of the author. All other rights reserved by the author.
I learned a lot from this first sprint. A lot of issues were being run into and as a team we were able to overcome these obstacles to all continue. Something that I learned that collaboration can often lead to success because you may learn something about a topic that you may not know. Next I will explain some of the tasks our group has completed. First, we had to make sure all of us had a sprint backlog. These included tasks for our sprint timeframe that we should be able to complete. We setup a group environment on GitHub to clone our ng2-amrs repositories so we could get oiur AMPATH portal up and running. This is where we, and many others, ran into most of our problems. A lot of us had many different errors so it was very confusing trying to find fixes for all of us at first. We coordinated with other groups via slack channels in order to first find out who was having what errors. After posting about the errors and discussing them in the slack channels and amongst each other at our meetings, we started to research for solutions.
The fix fix for this was to run two commands in the node modules folder that fixed the package.json file. After this, we ran “npm run build-prod” and then this fixed the issue.
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.
Often times we feel as if we may know how to do something, when in reality we may not know. Some problems that arise can may seem familiar but often times need more digging to figure out the answer or solution to. The Expose your ignorance pattern explains this by growing yourself in order to find a solution. The pattern states that we are not going to know every little detail about every software or domain we need to use in our jobs. There are people depending on us to perform a task, but the issue is what exactly do we do when we can’t overcome these obstacles? Even if you don’t know what you are doing or aren’t aware of a certain situation, it is always better to atleast look like or be willing to be competent in whatever the task at hand is. One great point that I think this pattern brought up was conceding your pressure and just telling your clients or colleagues that everything is okay, even when it is not. If you just tell people that thing are okay even though they aren’t this can lead to a massive snowball effect.
For example, maybe you don’t understand how to use the companies’ software that you are working for yet and there is some things you either want clarified or need more time on. If you were to just say that you understand everything, what does this precedent set? It tells people that you are okay to move on to the next thing and most often than not, whatever that “next thing” is, it most likely builds upon the previous task or requirement you should understand. Sometimes it is just better to be honest and let your team understand that although you may not currently understand what is happening now, you will be able to learn it. As long as you show you are able to learn the materials and keep up even when you are behind, you will always be valuable. Ask questions because not only will it help you, but it can often times help whoever is answering the question with something they may not have known about either.
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.
For this blog post, I will be discussing the Apprentice Pattern, Expose your Ignorance, found in the text Apprenticeship Patterns. This pattern piqued my interest. It discussed how to deal with inevitably not knowing something. It is comforting to hear that I am not the only one who sometimes feels out of their depth.
This pattern gave me a few things to work on. It can feel natural to tell people what they want to hear, but that isn’t a good way to build trust. I know it may seem obvious, but it is very easy to fall into that trap, and I know from experience. I like the idea of building a reputation on my ability to learn rather than what I say I know.
Ignorance isn’t something to hide — it is a chance to grow. This brings to mind a “growth mindset,” which means that instead of seeing challenges as something that sets one back is instead something that can be learned from and used as fuel to grow. It is clear that this book adopts this idea, even if it isn’t necessarily one of the patterns.
The pattern made me think of my ignorance in a new light. Instead of trying to pretend that I know more than I do, I should make it well known what I don’t know. My reputation shouldn’t come from what I know, it is my ability to learn new things.
I also liked how they wrote that being an expert is not the goal. The example of a marathoner having strong legs from running even if that wasn’t the goal seemed like an apt metaphor that being an expert is likewise a byproduct. In addition even if we are experts in one area, we will always be ignorant elsewhere. We should relish in what we do not know. Ignorance is something that should be welcomed because it means we are learning and growing.
I feel this pattern is tougher said than done. It is a simple concept, but it might take years to fully master. That being said, simply being aware of my shortcomings in this area is a huge step forward. This is something I intend to start immediately in every project that I am currently working on and every project in the future.
From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.
On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my forth individual Apprenticeship pattern I have chosen “Practice, Practice, Practice”. I will first summarize the pattern and then I will state my reaction of this pattern.
Practice, Practice, Practice summarized
It is important that you take the time to practice your craft in a comfortable stress free environment where you can make mistakes and learn from them. It is just as important to have constant feedback in order to avoid developing bad habits. According to the book, “The key to this pattern is to carve out some time to develop software in a stress-free and playful environment: no release dates, no production issues, no interruptions. As Dave Thomas says of practicing, “It has to be acceptable to relax, because if you aren’t relaxed you’re not going to learn from the practice.””. This pattern tells you about a good tool to use. That is a coder’s dojo, which is a place where people can perform code katas regularly and publicly within a tight-knit community of craftsman. This tool is also good because it allows constant feedback. Another good tool to use is one of your old programming books. Pick an exercise from the book that is not too easy for you. Then, try to solve it from scratch for once a week for about a month. By doing this it will allow you to see how much your solution has improved and sharpen up your skills.
This pattern shows you that a good craftsman, must constantly practice in order to sharpen his/her skills. It also, tells you to constantly receive feedback of what you practice because it helps prevent you from forming bad habits. Personally, I agree with this idea. I found that this idea is not just interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think because it has made me realize that I need to “practice, practice, practice” on this long road of Software Craftsmanship.
Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.
From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes 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.
It’s fair to say that I am nervous about entering a computer science job and working with a professional software development team for the first time. While I will be fortunate enough to graduate with knowledge of agile development, I have a feeling that it will be quite different to participate in development with more experienced coworkers, rather than with classmates with similar skill levels as me. This week’s apprenticeship pattern, “Sweep the Floor,” described various ways that I can potentially overcome this initial worry of fitting in and being able to contribute on the team to the best of my ability.
Sweep the Floor discusses my exact predicament: being the new apprentice on the team and struggling to find my place within it. The solution for this issue is to work on simple and more mundane, or unglamorous, tasks which the rest of the team may find more tedious. Or, the apprentice may focus more on the “edges” of the project (rather than the “core”) to minimize any risks to the project that could come with putting a newcomer on the more difficult parts of the work. These tasks are still necessary for team success, and therefore make great experience for an apprentice who is just starting out in the field. By completing these seemingly unimportant tasks, the apprentice can show the rest of the team that he or she is capable of producing quality work that benefits the whole group.
Before I read about this pattern, I was already aware that as a new member of the software development team, I wouldn’t have as much responsibility or experience as other coworkers who have been on the team for a longer period of time. This pattern gave me a better sense of direction, in terms of more specifics for the kind of work I could expect to complete when first starting out on the development team. I have always found some reassurance in the thought that new employers and colleagues expect fresh college graduates to not have much experience outside of the coding projects they completed for classes. This pattern helped further encourage me that I can make the most of this “newbie” status by finding important tasks to do and still gaining valuable practice.
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.
I decided to dive in with one of the first patterns of the selection, “Your First Language”. I chose this one because I was curious about the tips that the author would give individuals trying to decide on a first language, as well as to see if any of the tips translated for someone like myself, who is trying to branch out into learning more and more languages. This pattern breaks down the steps to choosing a first language and gives several factors for why you should potentially choose a language but makes sure that it is clear that these are tips and not the only reasons for selecting a first language. After picking the first language, the pattern lays out some tips for how to actually learn the new language. The pattern also lays out a simple means of learning more languages down the line and why someone should pick a particular different language.
The only part of the pattern that you could argue I disagree with, is the complete focus on your choice being driven by potential physical mentors. With the internet and communities within the internet, it is relatively easy to find mentors online who are more than happy to answer any of your questions in understanding a new concept or a language for that matter. Overall, I found this pattern VERY useful!
From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.