Category Archives: cs-wsu

“Practice, Practice, Practice” Apprenticeship Pattern

I am writing this blog post about the “Practice, Practice, Practice” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about the desire to improve and learn despite not having the opportunity to do so while working. The obvious solution that the book presents is to practice on your own time, while not working. Practicing something is certainly important; the process of practicing working with some idea is actively developing experience with that topic, rather than just reading about it and recognizing it. I have spent a lot of time reading about many different algorithms, and a lot of it does not really stay until I make it relevant by directly implementing it myself. The only consequence of doing this is educational, though; doing this while working would not be the appropriate time. Practice generally does not yield some purposeful product, whatever it is that is created in the end is only for the sake of experience. The book brings up a point about practicing the wrong things. I think this can be important. I have spent a lot of time practicing trying to write programs using the fewest amount of characters possible, which for obvious reasons is not a good way in general to go about programming. The result is typically a barely readable mess of what amounts to glorified machine code. I became good at it, but certainly the time would have been much better spent practicing something more practical than code golf. After gaining a lot of experience with different topics that I found interesting, I have been able to recognize situations where things I have practiced in the past are relevant and knew how to implement them as a solution. What I have noticed along the way is that now I would rather spend my time applying what I know than taking the time to practice something new and not produce anything meaningful. I still am interested in learning about a lot of things, but practice takes a lot of time, so the only way to learn is to take the extra time.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Retreat into Competence

For this week’s blog, I am going to be talking about “Retreat into Competence” pattern from the Apprenticeship Pattern book. This pattern is about realizing how little you know, or when the new challenges that you have taken are not working out so well.  As you work, there are going to be many projects and challenges that are gonna be assigned or you are going to take. Sometimes, these challenges can be something you have never done before, or it might be a roadblock that you are gonna have to clear and these challenges are making you realize how little you know.

The book’s solution to this pattern is to “Pull back, then launch forward like a stone from a catapult.” They said that you should retreat briefly into what your confident on doing and regain composure. Take some time to build something that you know how then use that experience to see how far you’ve really come and measure what else you are capable of. Being an apprentice there is going to be a lot of ups and downs. You will experience learning new technologies and use it to leverage your knowledge that would deliver value to your customers. But you will also experience terror, roadblocks that seem impossible to pass through. These challenges can be overwhelming at times but it is to be expected if you want to progress.

I totally agree with this pattern. There are going to be times when you will encounter problems that seem to be unsolvable or problems that will show you just how much you actually know. In life there are going to be problems that seem impossible to solve, we get overwhelmed and try to forget about it, which becomes a bigger problem. I like how the pattern suggests that you look back on what you know how to do first.  It will show you how far you’ve really come. This process might give you hope that no challenge is impossible, you just gotta go through all the learning again.

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

“Be the Worst” Apprenticeship pattern

I am writing this blog post about the “Be the Worst” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of the pattern, it is about trying to be in the presence of people with more experience than you so that you can learn from them, as opposed to being experienced already and not having the opportunity to learn from others. I can see this being a useful way to learn, but at the same time it does seem a bit selfish to put your own education above the quality of whatever it is you happen to be working on with everyone else. To be the worst may indicate that you do not actually belong where you are while you exploit the opportunity to learn. If this does not turn out to be a concern then it is still the case that you would not be performing as well as anyone else, so it may be discouraging to have a responsibility and not be prepared for it. Maybe being the worst is taking it to the extreme, but the more general goal of not being the smartest person in the room is a good way to learn from the person who does have more experience. I have been programming in the same language for the last decade and I now know everything about the language down to the exact differences between each version, and that came from being involved with other people who had knowledge that I did not have. Now there is no learning opportunity after having mastered this language, so since I have not nearly the same level of experience in any other language, it would be a significant learning opportunity to surround myself with experts in another language that I intend to become versed in. Since I have learned everything I needed to know to do the things I want to do, I have stopped learning at the same rate. Moving forward into a career, I expect it will become necessary to be just as experienced in more languages, so engaging with experienced programmers who use those languages will be beneficial.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

The Deep End

For this week’s blog, I am going to be talking about The Deep End pattern from the Apprenticeship Pattern book. The Deep End was about taking that big step in your career. Grow your skills, your confidence, and your portfolio. Challenging yourself with bigger projects. This may involve new tasks, new teams, and new places.

The book suggests that you dive into the deep end. Waiting for opportunities until you’re ready will only set you back and be stuck doing mediocre work. So, if offered a high-profile role, take it. Growth only happens when you do something. But of course, there are risks involved in taking on bigger projects or high-profile roles. If you get it wrong, instead of growing, you might shrink. It might destroy your career as a software developer. But the risk is also the only thing that can help you grow, so take the risk with caution. They also suggest that you list down all the projects that you have done. What is the biggest successful project you have worked on, and the biggest codebase you have built on your own. After writing them down, use them as metrics to measure if you are going to be ready to take on a bigger project with more responsibility.

I found this pattern very interesting. Not because it is something new but it is something that I can relate to. I am usually the kid in the back of the room. I usually only do what is expected from us and do the minimal thing to pass or get a good grade. Whenever there is group work, I almost never volunteer to be the leader. I do not like having to bear that responsibility. I am scared that I would do something wrong and let down the team. Scared that I would not be able to do my role as a leader. Now, I am trying to change that. I am trying to get more involved when it comes to team projects. I am now trying to lead everyone when they do not know what to do. I try to make a decision that everyone can agree to. This pattern did not really change the way I work, but it reminds me that I still need to improve with being a leader.

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Not a lot has happened in the last two weeks. There has not been a clear assignment given to be accomplished individually or as a team. On the first class meeting of this sprint, I helped Matt get through the final errors to get the ng2-amrs, since he was seeing the same errors that I had seen and figured out how to get through myself. After installing the right version of node, and then following the determined steps to fix the series of error messages that come up after trying to run npm start, it says compiled with warnings and does not error and the AMPATH login page comes up when visiting localhost:3000 in a browser.

Once he got it running, everyone on the team was able to run it without errors, so we had nothing left to do but vaguely review some miscellaneous information about JavaScript and angular. After that, our team did not meet in class for a couple of days or class had been canceled. It was not until Thursday during the sprint review that we started to get something to do, but that was the last meeting before spring break, so we did not get a chance to actually start anything, only to look at the new information that has been given and begin to process it.

From watching the first of the six AMPATH videos that we were sent, it looks like we are being given an existing user interface and it is up to us to implement the desired logic and behavior to have it interact with the medical records back end. The videos walk through some of the buttons and elements that were already placed together on the front end, and some specifics are described about what the elements are supposed to be for and how they should interact with the medical records data. From here on, we will finish watching the rest of the videos to better understand what they explain and what is expected of us, and we will have to decide among the other teams who is doing what, and figure out what it is we are actually going to be doing and how to do it. From what I have understood so far, I think that we are going to need to read a lot of the code that has been written so far, and then while we are writing more code to implement the new front end features, we will be referring to the existing code in order to find out how to access or manipulate certain data and objects. Depending on the amount of documentation that exists, it is possible that we may need to come up with our own documentation just to keep track of how everything works. I think that our previous experience programming in typescript during the last semester should be helpful while writing the code for this, although this does seem like it is going to be significantly more in-depth in certain areas.

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

Practice, Practice, Practice

On our journey to become master craftsmen, we must always remember to revisit the fundamentals. Sometimes, the hours spent learning and becoming better at a new job leaves us little time to revisit the fundamentals. Without the room to make and learn from our mistakes, we risk, as best, stagnating and at worst, reinforcing new, … Continue reading Practice, Practice, Practice

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 2

Another sprint ended for our capstone class and we are starting to be more familiar with the EMRS source code, and the testing ways using Karma. Testing with Karma is a must have knowledge for all Angular programmers. As we started the second sprint with zero knowledge in this area, everyone on the team had … Continue reading Sprint Retrospective 2

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

For this week’s blog, I will be talking about our second sprint working on the open source food pantry project. This sprint was a bit unique as to the first one since it is mostly about communicating with the customer.

In this sprint, I learned a lot about the communication between us, the developers, and the customer. I learned that it is not a simple process. At first, I thought that it would just be a simple interaction, they give us what they want or how it should look like, and then we try to create it and meet their demands. But that is not how it goes at all. There was a lot of interaction that we needed to do since the customer does not know what they really wanted. There is also the issue of communication. Most of the time, it is hard to get hold of the customer and we have to wait for them to respond to us before we could even move on with what we are doing. I also learned that starting a new project is like an open-ended question. while planning on this project and asking the customer questions as to what they want, it just seems like they do not really know what they want.

During this sprint, we have decided to change our focus from making the foodsaver REST API onto making the food pantry software since the other team has already made it. This sprint was mostly about communicating with our customers. The first meeting with the customer is with Serena. Serena works on Thea’s food pantry and knows how the pantry operates.  During the interview, we asked how the pantry operates. They have a google form that is filled out once by every student that goes there. It asks about the number of people in their household, their income level( whether they qualify or not), and what kind of help or services they are already receiving. If they already filled out the form, they only need to swipe their card preferably but for now, they just take note of the student’s ID number. Then they weigh the items that are being taken by the student and record it. They only keep track of how much weight is taken and how much weight is left on the pantry. 

The second meeting that we had was with Joanne, she has been helping guide the student-led-food-pantry initiative. Before our meeting with her, we tried to come up with questions to ask. Most of the questions we came up with was just a clarification on the information we got on the first meeting. In our meeting with Joanne, we asked her again about the forms and what kind of information they are storing. Since they cannot give us private information, we asked if she could just blur out the pieces of information and leave the column headers. This meeting was mostly trying to learn what the food pantry does and how they get food in and out. This meeting also opened the topic with the one card system and how they want it to show information about the student once they swipe.

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Confront Your Ignorance

For this week’s blog, we will talk about confronting your ignorance from the Apprenticeship Pattern book. This will be a continuation from the last blog Exposing Your Ignorance.

Now that you have let your teammates know that you are lacking in some skills, it is now time to deal with your ignorance. There are tools and techniques that you need to master but you do not know where to begin. Some of them are things that are expected knowledge from you that everyone around you already knows.

So what should you do?

The book’s solution is to pick one skill or tool and actively fill in the gaps in your knowledge about it. How should you do it is up to you. Whatever works best for you. For some, the best approach is reading all the introductory articles. Others find that looking at the code is a better way to understand it. They also recommended asking around if anyone is also trying to master these skills or ask a mentor that already have these skills and if they are willing to share what they learned.

I find this chapter interesting since it was tied to Exposing Your Ignorance chapter. To do this pattern, you will need to expose your ignorance first. Using this pattern in isolation might lead to a culture where failure and learning are unacceptable and everybody just keeps to themselves. Also, your employer has certain expectations from you and might not be understanding of your educational needs that would get in the way of the successful delivery of its project.

Confronting your ignorance is probably one of the things that you will be doing over and over again in your workplace. Most likely, your first few months in the job would be a learning curve for you. Figuring out what tools they use, how it works, and how you could use them would be the first challenge you will face.

This pattern changed the way I think about confronting my ignorance. Usually, I do everything alone and try to solve things alone. But that seems like a band-aid solution to the problem. It is better to ask people who have mastery of such skill and see if you are doing it the right way, so in the future, you will be more knowledgable and can be a master of this skill as well.

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

Expose Your Ignorance

This week’s blog is going to be about Exposing Your Ignorance from the Apprenticeship Patterns book. This pattern tackles the problem of not knowing other technologies in the workplace. The people that are paying you are expecting you to know what you are doing at the very least. Your managers and team members need confidence that you can do the job, but you are unfamiliar with other technologies. It happens to everyone. Especially if you are a new hire.

This pattern is very interesting to read. Normally, we do not show our weaknesses to others. We tend to keep it in even when we are having a hard time dealing with something. I would assume it also happens in the software development industry. No one wants to be seen as ignorant and be looked down upon that is why sometimes you try to hide these weaknesses. But this pattern is different.

This pattern suggests that you show what you are lacking.  Telling people what they want to hear is not a good way of building relationships and them having an impression on you. Tell people the truth. Let them know that you are getting the hang of it and are still in the process of learning. Reassure them with your ability to learn and not by lying to them that you know how to do it.

The most effective way to do this is by asking questions. There are no stupid questions. That is what every teacher would tell you. But it is not easy. Sometimes, people have expectations from you and it can be hard to ask “stupid” questions. There is also a sense of pride when asking a question. Sometimes you would look around you to see if you are the only one who did not understand.

I personally have this problem. I almost never ask a question. I always thought that I do not want to bother the whole class asking a question that seems like only I have a problem with. I would usually just tell myself that I would just look it up online and answer the question myself. After reading this pattern, I would definitely try to change that habit of mine.

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