Author Archives: cloudtech360

Sprint 3 Retrospective

Our third and final sprint for the semester was our strongest sprint to date. Everyone in the team could feel that we were really hitting our stride and solving issues as they were being created. We were able to look at what went wrong in our prior sprints and not get trapped in the same pitfalls that we encountered early in the project.

The Good

We were laser focused on what we needed to do. Our productivity and communication levels were at an all-time high which really helped in the amount of work we were able to produce. We were also able to realize when an issue was more than a bite-sized problem and successfully broke them up into smaller issues as needed. We had a clearer vision of the direction we wanted to take the application in and for the most part we met the expectation we set for ourselves this sprint: A demo application that highlights its main functionality.

The Bad

I mean… There wasn’t too much that really went wrong with our workflow during this sprint. I think the feeling that we performed very well was very tangible to anyone watching us operate as a team or looking at our team’s activity on the project repository. The only bad thing that would come as a result of this sprint is that we are concluding our work on our application that we witnessed grow from inception.

What could we have done better?

I feel like the only thing we could’ve done better was perhaps having a longer discussion on how we envision the app to look in the future. Leaving better instructions for the next team of students who will work on this project is the only thing that comes to mind when I think about anything we might have lacked in.

Contributions that I added to the application include

Writing Portion:

Create a writing page for an examinee to record the prompt they heard from the proctor. They will type out what they heard instead of using their finger or a stylus to write it out. The current version of this feature is a temporary solution until a way to implement the correct functionality is discovered.

Create a page that holds all the prompts the test proctor will ask the examinee to write(type) in English. A .csv file named “sentences” was added into the projects assets folder. The Prompts.js file reads from and parses the sentences from the file into a list which is then displayed in a ScrollView on the page.

Adding React Native Paper styling to Writing and Prompt pages. We decided to use React Native Paper styles throughout our application. In order to remain consistent with the application design, I added card features for the elements on each page.

Merging of Writing page and Prompt pages. After the pages were created a teammate suggested that we merge the pages instead of having to navigate too much. This was a great idea because it was much easier to implement than having to move from page to page as well as improving the UI.

Reading portion:

While working on my own issues, I aided my teammates in working with our app’s counterpart to the writing portion. The bug we encountered involved displaying a question from a list of questions on a separate page. While we couldn’t resolve the bug itself, we were able to verify that it is possible to display another question successfully on a “new page” but do not have the means to display the correct one at the moment.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Dig Deeper

While reading the “Dig Deeper” pattern, all I could think of was how the authors had just blown-up whatever spot I thought I was hiding in. As a student, I typically would study or pay attention to the things I needed to work on in terms of meeting an assignment deadline or just getting an assignment to work somewhat as specified. Recently, while working on my final robotics project, I ran into a multitude of issues that didn’t allow me to complete the project how I intended. While trying to understand the vast amount of literature the internet had to offer on C++ programming, I just couldn’t overcome every issue I ran into. The main problem I encountered was the same one that’s defined in the book. Cutting corners during tutorials, and simplifying complex issues took an immense toll on my understanding of the language and the structures it had to offer in solving my problem.

The suggestion in the solution is something that I want to include in my arsenal for the future. To be able to dive into the depths of material and find out why things are made how they are is a more desirable trait than complaining or feeling flustered that certain things are too difficult or complex to understand. Digging deeper into tools and technologies that I’ve worked with might also make future interviewers more interested in me as potential candidate for a job. For example, during the entirety of the semester I was in a group that worked on building an application for people who want to prepare for their U.S. citizenship test. I wasn’t apart of every part that was developed but being able to learn and reiterate what my teammates did and why they did what they did is just as important as the work that I contributed to the project.

This pattern is the blueprint for the type of knowledge for the types of skills I desire to have. Instead of wondering why people decided to build things their way and replicating their choices, I want to be able to build technologies of my own and be able to make my own informed decisions along the way as I craft my own software or technology.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Learn To Fail

“Learning How You Fail” is all about realizing that you’ve grown in mastery but at the same time remain stagnant in other areas. Rather than trying to overcompensate for shortcomings, taking the same effort and seeking introspection instead seems to be more worthwhile. When I think about it that way it makes sense, although breaking out of the habits I’ve already formed will prove to be difficult.

I do agree with the sentiment of this pattern, but the thought of someone’s natural ability to either be great at something or bad at something comes to mind. Is it worth the energy to be less bad at a certain thing when you can excel elsewhere? At the end of the day, I guess that answer varies from person to person. But there is something admirable to say about someone who you’ve watched improve at something they were originally horrible at.

The “Learn How You Fail” pattern seems to be a preemptive strike of some sort. Figuring out how you will fail doing something allows you to do your best to steer clear of the pitfalls that lead you to your failure. Throughout my life, I have been one to make the same mistakes repeatedly. I’ve always said that I’m just persistent, and I am. But I would probably gain a lot more from my persistence if chose to analyze what had gone wrong, rather than to try and brute force my way through certain things.

The scenario painted in this pattern is to write some code that performs a binary search in a simple text editor and continue to fix the code until we believe it’s perfect. Once the code has reached our level of satisfaction, we also write test code from scratch. I think the point of this exercise is to realize that we ourselves may not be as perfect as we think we are. While I feel like this pattern can be applied to software apprenticeship, I feel like it’s more suitable “life advice”. Perhaps I’m not opening my mind enough and that’s a failure I could learn to learn more about.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Sweep The Floor

The sweeping the floor pattern is all about earning your dues. It’s a rite of passage for any apprentice to earn their place in their respective workshops. Over the years I’ve gotten my haircut countless times. In a barbershop, you’ll likely come across a younger individual who all the barbers are always cracking jokes on. This individual also has a very important role to play within the shop. Although the shop’s main attraction is the barbers, the individual or individuals who sweep the floor are the unsung heroes. They allow the barbers to continue doing their work without having to spend the necessary time to clean up after themselves. The work the sweepers do come with a couple of benefits. Allowing them to earn some cash, as well as giving them an opportunity for them to learn how to become a barber. With all the time they spend in the shop, they get to watch closely from the sidelines as the barbers portray their skills. This relationship can also be seen in apprentices who wish to become software developers.

The authors make mention of things you can do in terms of earning your keep at your internship. Picking up the grueling time-consuming tasks that seasoned members of your team don’t like to do or don’t have the time to do is not only a great way to learn something new, but it also helps your team out. Although your contributions may take significantly less skill, your contribution is still valuable. The message here is to make the most out of each opportunity that you’re given.

While I agree that these sorts of things should be taken up during an internship or apprenticeship, I do not believe that taking up these sorts of tasks as an employee is a suitable thing to do. There may be times where picking up less technical work may be necessary, but always taking up these types of tasks on your team could allow your teammates to feel comfortable with giving you bottom of the barrel work regularly, which could speak for how competent your teammates think you really are.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice…

The authors of the Apprenticeship Patterns book do an amazing job of capturing my attention. The opening quote that the “Practice, practice, practice” pattern starts off with demanded that I pay attention to what comes next.

“People we know as masters don’t devote themselves to their particular skill just to get better at it. The truth is, they love to practice—“

When I read this quote part of me shimmers with hope because of the proper guidance I was just given to help make it in my future, and another part of me frets because practicing can be difficult and I don’t want to struggle or face the hardship of practicing. Now my issue with practice isn’t that it can be difficult, I don’t mind taking on a challenge. My issue with practice is that I don’t want to be practicing but doing it completely wrong and then feel like I have been wasting my time. The way I picture it is like doing a bunch of push ups but the entire time you’ve been doing them your back was “U-shaped”. You don’t know any better until someone comes along and tells you that you’ve been doing it wrong the whole time. Meanwhile you’ve “mastered” the U-shaped push up but in reality there is no such thing. All the arm strength and muscle memory you built to do that unrecognized form of exercise was for naught, and that’s how I feel I might end up when practicing alone. The pattern does recommend practicing in public places, doing “kata” or finding a coding dojo to code amongst others and have these flaws pointed out as you practice. This sounds like something that would cause my nightmare scenario to never happen but there comes this slight embarrassment when thinking about asking for help or making a mistake in front of others… I suppose it’s a small price you pay while getting better. After all, its better than the former scenario. An old manager of mine once said something to me that still sticks with me today “If you ask once, you’ll only feel dumb once. But if you never ask, you’ll feel dumb forever”. Perhaps I should do more than just think about the profound words and apply them.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Expand Your Bandwidth

The Expand Your Bandwidth pattern gives advice that makes suggestions based on how the title sounds, broaden your horizons.

In learning how to traverse the field of software development there are many tools one must learn to become a successful developer. One type of solution will not work for every problem that a developer faces and that’s why it’s important to never stop learning. The problems will never stop changing and that means that sometimes the application in dealing with or recognizing the problem might change too. The authors mention that an apprentice “must develop the discipline and techniques necessary to efficiently absorb new information, as well as to understand it, retain it, and apply it.” Ways to start applying this pattern include signing up for software development newsletters, following “software luminaries” on Twitter, and even taking free courses online.

I aspire to be a better developer everyday and sometimes finding the energy to become better doesn’t exist. These moments are the most crucial in terms of my own development. I remember being a part of a mailing group where you would pledge to setting aside a dedicated 15 minutes to learning something new in the software development field or use the time trying to write a part of a program. During those 15 minutes your attention should be undivided, and you should be hyper focused on the thing that you are working on.

I agree with the sentiments of this pattern. Being able to “to be able” in this field comes with a lot of knowledge that needs to be drawn upon. Even if you are not knowledgeable about something you should be able to have the skills to know where to look to find information related to problems you are trying to solve. Once the fountain of information has been located, being able to consume it and properly nourish one’s mind is also a skill that one must obtain. Just knowing where to look is not enough. One thing the authors do mention that I may have overlooked is knowing when to stop expanding your bandwidth. This is really important because if you spend all your time trying to learn everything it will actually have a negative impact on your everyday life, in terms of work and possibly even family. This is why I think the 15 minutes a day example is a good starting point to figure out what kind of balance you need to “stay frosty”.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

With our second sprint concluded, our team made significant progress but also experienced large amounts of stagnation. I think this was due to the weeklong spring break smack dab in the middle of the sprint that caused nearly everyone’s productivity to drop to all-time lows. The biggest win we achieved was learning how to and getting our dev environment containerized. A few of the mistakes we made during last sprint, we made again this sprint.

The Good

We made a lot of progress on our board in terms of organizing and giving tasks proper descriptions so we could revisit them later and know what needed to be worked on. While it seemed like we didn’t have a lot to show for the work that we did, we did gain a lot of valuable knowledge that will help set us up completing tasks that weren’t able to be finished this sprint.

The Bad

We repeated a few of the same mistakes from the first sprint by not communicating with each other effectively. While working on completing issues on the board, it became apparent within group that issues were mostly resolved but small portions of them remained incomplete. Because of this our board looked like not a lot of work was completed.


We should be revisiting the board often and make changes where necessary. We need to effectively get better at recognizing when an issue needs to be broken down into smaller issues. Our communicating skills are getting better, but it still needs some work. We came up with the idea that we would do our best work outside of class and use our time together in class to bring each other up to speed on what we have done and communicate what still needs to be done. Lastly, we can make sure we’re using our class time as efficiently as possible by making sure we’re staying on track and not getting sent down rabbit holes of information.

How I Contributed

I was tasked with creating a drawing feature for the application. This would be used as a means for a test taker to be able to write down what they hear from the proctor. I spent the entirety of my time trying to implement this functionality into our application. At first, I thought I would try to learn how to create this type of function from scratch. After lots of tinkering with PanResponders and InteractiveViews, I realized that this sort of thing would not be as simple as I thought it would be. Instead, we found a project on GitHub called React Native SketchCanvas. This program was being shared under the MIT license and had all the functionality we were looking for. We just had to figure out how to get it to work in tandem with our application. It was around this time that we figured out how to containerize our development environment.

While trying to get the SketchCanvas dependencies into the container, I kept on getting errors from the terminal that were complaining about the components in the SketchCanvas code. It turns out that the software that we use to test our application Expo is not fully compatible with the SketchCanvas and will not recognize certain custom components its comes with. The SketchCanvas seems like it was a class project someone at MIT worked on because it doesn’t seem like there’s any active support in its GitHub repo. While good research was conducted during the sprint, ultimately this task will continue on into the next one.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Be The Worst

Sometimes being the worst is not the worst thing to be recognized as. It can be a scalable thing. In sports for example, being the worst player on the Boston Celtics may seem like a bad position to be in. The reality is that your skills are far more impressive in comparison to the average person who watches basketball, and you should give yourself more credit for even making it into the league. The “Be the Worst” pattern is one that allows those who exercise it to never remain stagnant. While it is nice to admire yourself for all the progress you have made along your journey, you should not bask in these accomplishments for long periods of time.

There have been many times in my life where I’ve felt like I’ve done all that I needed to do and “now I can just chill”. That same attitude has also gotten me in a few binds during my academic career. These things occurred because I felt like I was doing my best at something and would always be the best even if I didn’t continue maintain a certain level of excellence. It seems like the view here is that being the worst is the best and being the best is the worst. In other words, you have nothing to lose if you’re the worst and have nothing but the potential to grow, but if you’re the best then you must maintain being the best and potentially face having to fall from grace.

While I understand the message this pattern was trying to get across, I feel the messaging could possibly be misleading. The author mentions being the worst person in your team that produces good work can “make you feel as if you are performing better” when you could not be performing at all. While I feel like this pattern is helpful for myself, the advice given here should be taken with a grain of salt. To me, the most important part about being the worst is making sure you have the will to become the best and repeat the process.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

The White Belt Pattern

The white belt apprentice pattern refers to the part of the movie where the main character thinks they know it all, but instead suffer tragically in some way due to their ignorance. This pattern recognizes that now that you have some skills, the real journey begins.

Assumptions can sometimes be dangerous and can impede your learning. Many times, when I’m trying to learn something, I associate with how it can be like doing something else. While this can be helpful to get me to remember how to do something, this method can also leave out the realization of other possibilities that a certain strategy offers. For example, throughout experimentation with different ingredients and brewing strategies, today many different brews of beer exist. This wouldn’t be possible if these craftsmen didn’t take the time to forget what they knew about making beer already, otherwise they would have just crafted the same one beer repeatedly.

While I find the information in the pattern interesting, I really wonder if I can apply it in my own endeavors in programming. I become doubtful I guess because this is a new way of thinking about how to learn for me. However, I feel like the explanation of learning your second language is put perfectly in the book. The need to feel productive is a dominant urge that I have, but that need must be sacrificed sometimes to learn something new and improve upon my skills. In fact, the book says that this is the most productive way of doing this so in turn, I guess nothing is really being lost.

Becoming comfortable with not being great at something after being great at it for the sake of learning is something I need to get better at. Learning how to do things with my left hand will be helpful if I cannot do things with my right hand, although it would feel naturally uncomfortable to do so. While I am open to and applaud the idea of this pattern, I can see myself struggling to apply it in my own life.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

The Pattern Of Enthusiasm

I think an apprentice should portray acts of enthusiasm for whatever they are aspiring to learn. I’ve found myself to have copious amounts of enthusiasm for learning how to program and becoming better at it. The issue I run into is finding ways to express that enthusiasm. I get giddy when I think about becoming a great programmer and I certainly wouldn’t want to rub anyone the wrong way because I came off as too much. My current composure and body language around others suggests that I am complacent, although I’m screaming with impatience on the inside. But I wouldn’t want to come across as apathetic for what I’m doing either. As I’ve been skimming over the different patterns in the Apprenticeship Patterns book, there have been many sections that made me feel like the authors were speaking directly to me and this pattern of enthusiasm is no exception.

The authors seemingly think that while being enthusiastic for your craft is an amazing thing, blindly expressing your enthusiasm can actually hurt an apprentice more than it can help them. With this in mind, it is important to curb your enthusiasm to an extent because you do not want to let the excitement you feel for the craft lessen because you don’t want to feel like a nuisance to others around you. As the authors put it, the excitement one feels is “a precious commodity” and I could not agree more.

The sense of discovery can be extraordinarily exciting. It is probable that individuals in well established teams are used to their routines, making discovery likely, but not exactly exciting. The authors mention that this sort of thing is predictable. Developers are always looking for better ways to getting “painful” work done more efficiently. This sounds more like searching for a sigh of relief rather than completing an exciting endeavor, and having with a hyper-passionate apprentice around probably makes tasks like these more grueling.

Finding a team that encourages your enthusiasm is important. An apprentice should be able to recognize a teams dynamic and see where appropriate to show their enthusiasm. If the team doesn’t seem like they would appreciate their apprentice’s ignorance, the authors recommend finding different strategies to nurture your need so that it does not jeopardize your opportunity to learn. However, if the team is open to bright and new fantasy driven ideas, the apprentice may offer new life to the team and boost morale.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.