In their chapter dedicated to Perceptual Learning, the authors offer some good advice under the apprenticeship pattern “Expand Your Bandwidth”. This pattern stood out to me because the main focus is on improving the learning process itself, not just skill building exercises.

The situation which the authors describe for us is an analogy which says that we as apprentices spend gain our knowledge by “drinking steadily through a straw”, and the fact that “there are seasons in an apprenticeship when one must drink from the fire hose of information”. This spoke to me because the fire hose metaphor is definitely how I feel. While it is important to take your time and learn the necessary development skills to their fullest extent, there are times in which we as apprentices need to open the flood gates of information and learn new skills and technologies as fast as humanly possible.

The reason why this pattern is called “Expand Your Bandwidth” is because that is the solution the authors provide for applying this pattern. They recommend a number of platforms such as a Google blog aggregator, following organizations on Twitter, as well as joining a technical conference whenever possible. I appreciate this advice, because it definitely makes sense to me to utilize the internet as much as possible as a vehicle for exposing us to as much information as possible, allowing us to accelerate our learning.

One important distinction or warning that the authors provide us budding apprentices is to not only know how to improve our volume and velocity of learning but to also know when to turn that off, and begin drinking from the proverbial straw again. While it is integral to be able to learn a vast amount of information efficiently, it is equally important to know when to slow down and focus more deeply on a smaller volume of data, allowing necessary skill development to accelerate as opposed to a broader learning approach.

This pattern definitely made an impression on me, and I will have to start applying that by taking up the authors advice to join a community or forum. Personally, I think I will begin by learning about contemporary industry related statistics provided by popular software development sites like stack overflow, etc.

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

I decided to read “Sweep The Floor” for this week’s post. This pattern discusses the idea that even if you feel overwhelmed and unable to contribute to your team, there are still ways that you can contribute. This means that even if you can’t tackle the complicated tasks and project straight out of the gate when you start a position, it is still important to be involved and demonstrate that you can deliver quality work in some way, shape, or form.

This is great advice especially for us newly graduating apprentices. When I was at both of my internships, I did plenty of “floor sweeping”. This was anything from writing up documentation, drawing out flow patterns, taking notes during meetings, and writing unit tests. One of the biggest benefits to sweeping the floor when you start a new job, is that you are learning the business logic first, then tackling the complex coding challenges that come with the job as well. For example, this way if your company is working on software that has five different user types and dozens of permissions that require different user types for access, you can learn how this works through writing the documentation and use this knowledge in future tasks for the software. You might even find yourself leading a discussion on the business logic even though you might not have contributed notably on a technical level. From my experience, it made me feel like I was one of the team. I could contribute to conversations, and offer ideas for possible solutions even though I wasn’t entirely comfortable with how to write the code for the particular task.

I also don’t think that this is limited to newly graduating professionals, or even in the world of software development. This line of thinking can be applied to all facets of business, as there are always menial tasks that no one wants to do but offer a learning avenue with a lower risk. When I worked in a hardware store/rental center, I had to learn the software we used as well as how all of our equipment worked. I cleaned the equipment and wrote up requests for customers as a way to learn more about diagnosing machines and giving customers better feedback when they called. Sweeping the floor is good advice both literally and figuratively.

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.

The third and final of “patterns grow out of an exposure to new information or a desire to acquire new knowledge: whether you’re practicing a new technique, building something in an effort to learn a new platform, or studying the source code of an innovative new open source tool.”. As this pattern “Breakable Toys”, is also important as 2 last blog posts. “Success is built on failure”, this is a well-known quote. But in the environment that sometimes does not allow for failure, we need to be both or leave some room for failure. We need to learn keep trying after failure, to be the kind of people who can succeed when faced with difficult problems.

Budget for failure by designing are good for side project. We want to have failure in the manage area, they need safe place to make mistake. When implementing the Breakable Toys pattern, make your systems relevant and useful to your life. This is good for our own personal project. In these project, we allowed to fail, we can try out new ideas and techniques. The person who get effect by these failure is us, not to others. The book suggests that a classic example of the use of this pattern build our own wiki. I think this is good idea, this require a lot of components work together: HTTP, REST, parsing, web design, caching, full-text search, databases … we can learn a lot from it. They need maintaining, so there will have thing to do, plus we could keep adding feature. This is great long-term project.

Failure and things go wrong are always happen in the tech industry. The important part is how to fix it and what did we learn from it. It is good for business to know this and leave some room to fall back in, like a backup system or good security team.

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.

I once watched a video by a self-proclaimed “lifehack guru,” where he talked about what he claimed to be a revolutionary new way to “think stuff done.” I always take ideas like this with a grain of salt, but in this particular video, I thought there was something to the advice he gave.

He said to look at your cluttered desk (or area of your choice) and to imagine it clean. The important part is this: you pause and take some satisfied breaths about how good it feels to have a clean desk. Note you have not done anything yet, but you feel the satisfaction of what it will feel like when you are done. Already, you should find that you have, without meaning to, probably thought of a few steps to achieving it.

That’s a long way of getting around to introduce the pattern, “The Long Road,” but the action that it suggests feels very similar. It suggests to imagine your future ten years from now and further, even the most far fetched version, and use that thought experiment to help plan your future career choices.

The “guru’s” advice was surprisingly helpful for doing something as trivial as cleaning my desk. I keep that advice when I do a lot of tasks now, even years after I have last watched it. However, so far I have only used it for short term and slightly longer term tasks that I need to do. I have not thought about applying it to something as significant as career goals, as the pattern suggests.

The pattern talks about keeping your sights set on the long term. This is something that I have been neglecting. I keep my head down and work hard on what is in front of me, but I don’t often step back to see the big picture. This affects me because when the pressures of school or elsewhere aren’t there, I sometimes don’t know what to do with myself. Without something assigned and a deadline, I can sometimes waste my time because I haven’t set myself goals.

It can be hard to set goals without the long term plan of where you want to take it. Otherwise it seems meaningless. What I liked about the guru’s advice was the pause to meditate on the moment where you accomplished your goals and hold that image. Although that is not mentioned in the pattern, I will use that step as I map out my future.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02s04.html

This pattern works with the situation that an upcoming software engineer has some knowledge, but not much experience applying that to practical situations. This is also under the assumption that the learning engineer is seeking out work with a suitable team of coworkers, or applying to a new job.

Following this, the pattern advises becoming proficient at skills that every team needs. This typically means executing simple manual tasks, allowing the apprentice to contribute before moving to a more direct role in the group. It is important to get to the point where work can be done without supervision or help from the rest of the team, so they can focus their time on other work. This type of work includes “writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice.”

On the other side of the coin, hiring managers are taking a risk by hiring a student or apprentice since they might require more help early on. To help combat this, concrete skills are an immediate and significant answer. Being prepared before getting hired allows instant benefit and payoff to the group that decided to take that chance, proving the worth and capability of the applicant.

This also helps when constructing a resume beforehand. Highlighting the areas that offer those quick benefits will help make the resume stand out, resulting in a higher chance to be contacted. Following this point, it makes sense to do extra research on the position first in order to train for the concrete skills that will be necessary once hired.

Although I feel that this can be challenging, they are very good practices. It can be frustrating if things don’t turn out perfectly, and an application is denied, but especially in cases where a dream job is on the line, the extra effort is very worth it. Even if the applicant is not hired, they likely can use or relate the concrete skills they’ve learned in at a different company.

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

Sprint four lasted from March 27th to April 8th. I was sick for the first class, but it wasnt hard to catch up on what the rest of the team was planning for the rest of the sprint. By the end of it, we’ve made a lot of progress, our group currently has a working prototype for our final presentation. After this sprint, or the next, we should be able to focus more on putting our presentation together since our project will likely be working and polished by then.

Recently we’ve brainstormed a list of improvement ideas to work on, polishing the project while we still have time. Some of the improvements include changing the header colors around, making the words bigger and easier to read, adding more buttons, and doing more with the title on the page. Many of these features are quick fixes, typically each one will take less than an hour. This sprint is likely going to change dynamically as we think of good ideas or quick changes.

We decided not to implement a login feature, or rather, it has a low priority and we will do it last if we have extra time on our hands. Additionally, the way we divide up work will be different than described in my last retrospective. Each button in the navbar is more of a placeholder, not exactly designed to perform a specific task other than change the text in the middle of the screen. Instead, each member will be given minor to moderate tasks to complete like the ones we planned out in our last class.

First we made sure to download the required angular material, our group member quoc took the liberty of creating a skeleton project and pushing it to gitlab. We all downloaded the skeleton, and have since made improvements on the style and layout of our navigation bar. Of the features we brainstormed, in class we quickly completed centering the text, which makes it much easier to read. Currently, we are also quickly working on changing the color values, which will also be completed soon.

My role in the group is to figure out how to have a nested button within one or multiple side bar buttons. The idea is that we could have a category named button that also works as a drop down bar, offering a few different buttons based on the category. My assignment seems not difficult, but also not as easy as changing color values, which is why some group members have multiple low effort tasks while I only have one moderate effort task.

Completing this by the end of the next sprint, along with everybody else’s contributions, results in a very usable product for our final presentation. To accomplish this, two tutorial videos were posted to the team backlog on github which each group member is assigned to complete as homework, though ideally the videos will help shorten the amount of time our contributions will take. I’ve linked both tutorial videos below:

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

For this weeks Blog Post I will be looking into the pattern known as “Study the Classics” where one is but to study the classics. The context behind this one is that you are self-taught or valued skill training over theory. The problem that would arise from this could be experienced people collaborating with you are constantly referencing concepts that they have assumed you read. But since you are value practice over theory you may have skipped over this reading/research. This will of course cause some problems, perhaps nothing serious but will lead to some confusion between the two parties. A solution to this is go back and study the classics if you will. If you were to pick up a book and think how old or out of date this book is, then you are probably reading the wrong kind of book. Successful apprentices will tend to focus on long lived books (classics) and use the internet or through practice to see how the information has evolved exactly. A classic they give in the excerpt is “The Psychology of Computer Programming” while this is “dated” wit h its punch cards and room sized computer parts the book was non the less relevant with is wisdom. Classics portray vital information to keep you heading in the right direction down on the Long Road, another apprenticeship pattern. By just focusing on classics you may take it to far and abandon more pragmatic knowledge and information that would enable you to improve your day to day craftsmanship. A simple remedy to this is to just mix the classics with modern, pragmatic books and/ or articles to your reading list. A way for this to act is simply pick up the oldest book in your pile. Or if you are looking through another developers book, take not of the oldest books and ask them why they still own them, sparking a conversation relevant to its wisdom it gave. Overall this is something I see myself doing down the road.

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

Read Constantly is a brief section, but it is an important apprenticeship pattern. Read Constantly is what it says. You need to constantly by reading and introducing yourself to new information in order to learn new ideas and improve. Most of the learning you do is from reading, whether its from sources on the internet or chapters of a good programming book. The more often you read and the better reading skills you develop, the better off you will be.

There is a book out there for every different programming language, every concept, every challenge you will come across in your professional career. I am currently reading a book that discusses the whiteboard problems brought up during many coding interviews. The book is long, and the content inside is dense, so it is important to read it carefully, take notes, and read it again to be sure of the information. That is my usual strategy for reading information that I need to learn.

My biggest challenge with reading constantly is feeling like I’m not absorbing all the information because I’m just trying to get through it. That’s why it is always good to do exercises in the book, if any are provided. That way you can do practical work alongside the reading that helps break up the monotony of reading and also gives you a different way to learn the content.

Another good strategy I use when reading is to take notes. There are often ways to boil down a text to its essential parts and the things you need to focus on and remember. Keeping notes, highlighting key lines, and keeping track of answers to exercises is a good way to maintain a reference if you ever want to brush up on what you just read.

Read Constantly is an important pattern when you want to learn something new or build a new skill. Good reading habits can open the way to learning lots of new things in a short period of time. It is absolutely the best way to learn quickly, especially if you are an independent person.

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.

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 seventh individual Apprenticeship pattern I have chosen to do “Retreat into Competence”.

Summary

There will be times, where you will feel completely over whelmed because you have taking on more than you can handle. Feeling over whelmed can be caused by other circumstances like having lack of knowledge and/or lack of understanding on just about anything regardless of complex level. Using the “Retreat into Competence” pattern is a good solution for this dilemma, even if  this solution is only a temporary solution. This pattern suggest that when you are way over your head the best solution is to take two steps back in order to be able to take 10 steps forward towards the right directions. The way the book puts it is to “Pull back, then launch forward like a stone from a catapult. Retreat briefly into your competence to regain your composure.” We must understand that to use this pattern we must set a time limit to our break or however long we choose to take a break. The reason is that if we take to long we can get stuck and never end up moving towards our true end goal. Another suggestion given is to seek guidance from your mentors because with their help and the new information you had picked up from your past experience will help you “be better equipped to handle the inevitable bumps on the road when you try again”.

My Reaction

This pattern helps you understand the importance needed to retreat into competence in order to have a clearer mind that can help you solve whatever, issue you might be facing at the moment. I agree with this idea because I found this pattern to be 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 should not panic if I do not know something but instead I should be taking steps back to see the big picture in order to be able to move forward and handle the situation I was presented with.

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.