This pattern also captured a very important issue that is often ignored. As a newcomer, you need someone to guide and coach you to get grounds in the field. We sometime failed to understand that only what is learned in class can’t take us to the field. The outside world has its own convention of doing things and a newcomer need somebody who is already in the field with experience to guide him. There are so many benefits for having a mentor. Working alone is the hardest thing you could face in the outside world and having someone as a mentor walking with you side by side or sitting with you face to face could save you a whole lot of time spent trying to figure out how to dealt with certain problems. Even though it sound very simple to say find a mentor, it is usually challenging to get someone who is willing to accept you as an apprentice.  Even though the writer talks about the field being young and which we can’t tell who is a master craftsman, I don’ think that is a problem. Because, no matter the situation is, those who are already in the field will have some experience that a newcomer doesn’t have. The issue here is everybody readiness to share what have been learned. Most people don’t want to share their knowledge with others because they feared their jobs would be taken from them. They also forget the fact that when you teach other of what you know, it helps you remember it all the time. In fact, it sticks in your mind forever. With regards to this problem, if you are fortunate to have many people mentor you, you will definitely gain enough knowledge to keep you going in the field. Another thing that every apprentice needs to know is that nobody knows everything and though the master has more experience than he has, they might both be learning certain things together. Regardless of whatever challenges I might face in the industry, with this whole ideas in my mind, I think I can survive in the industry.

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

At first glance, I thought this particular apprenticeship pattern seemed a bit absurd. The reason I say this is because I couldn’t imagine why anyone would actually want to “be the worst” in terms of skill level and knowledge on a team of seasoned software developers. However, after reading the rest of what the authors had to say in this pattern it started to make a lot of sense. This pattern reiterates some of the ideas presented in other patterns such as “The Deep End” and “Stay in the Trenches.” Essentially, the authors explain that it is more beneficial to be a “small fish in a big ocean” rather than a “large fish in a small pond.” What this means is that by taking on more difficult projects and/or working with more experienced developers you will provide yourself with more learning opportunities and walk away with a number of invaluable skills that you will pick up from your more experienced colleagues as well as your own personal experiences.

The authors note that this idea might seem crazy as it clashes with cultural norms that seem to advocate the idea that one should try to obtain the highest-paying position with the most superiority as soon as possible. They talk about how adhering to this cultural norm can curtail ones own self-development process by getting stuck in a position that lacks any real challenge. Another thing in this pattern that I found encouraging was the testimonials from various software developers describing their own experiences of “being the worst.” While you’d think that being the least skillful and/or knowledgeable team member would be an undesirable experience, all of the testimonials in this pattern seem to illustrate positive experiences of self-improvement and success.

At the end of this pattern the authors suggest that software apprentices should try to reach out and observe teams that operate at a high skill level in attempt to “be the worst” but in way that guarantees personal-growth. I think this apprenticeship pattern has provided me a new sense of confidence going forward. I’ve learned that it is completely fine to “be the worst” in a team of experienced software professionals because when you are, you have the largest number of learning opportunities that help push you further down the “long road” of becoming a true software craftsman.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

This Sprint was a good one. We gained traction last sprint and kept that that going this sprint as well. The momentum was not fully there as Spring Break was a bit of a speed bump to getting in to the flow of the project, and then afterward many end of semester projects came up that took my time. But either way, by the end we had the basic bare bones of an offline data storage service, a good stopping for next sprint to continue and hopefully finish off.

I continued experimenting with PouchDB this sprint, still on a separate angular project than the ng2-amrs project. This was mostly to avoid the hassle of installing and getting PouchDB working on the ng2-amrs project, as I had seen and heard frustrations from my team and others. This also let me worry solely on getting PouchDB working in a project and creating a successfully working angular project service to handle the logic of the offline storage, with methods for adding and getting documents from the PouchDB database.

I realized after a meeting with my team one day that the formatting of my code was different than the project, and so I copied the ng2-amrs projects tslint.json file into my own to make sure transferring any code I used would be easy and issue free. I fixed my function calls to use the recommended “ => “. After I made the code still work and formatted correctly, I created a new service called simply “offlineStorage”. It had a cunstructor that created a new PouchDB database, and just two methods, one to add a document to the database and one to get a document back.

The code in these methods was reworked code from the examples on PouchDB’s website, with added console logs to see the results. Then to actually test the service, I modified the .spec file for it by adding more tests than the default one. This part was done along with my entire team across two of our in person meetings. We were able to confirm that the service actually created a database, added documents of given data with a given id, and got documents back with a desired id.

The main issue that popped up with the tests were the fact I and my team were wondering how to interact with the documents received by using the get command. When checked the type of the response, it simply stated it was an object. I was not sure how to check the contents of the document and see if it was the correct one. On the last meeting our professor helpfully suggested we see if it was a JSON object, which it was. I felt a bit silly, but now with that issue solved, working with the documents we get from PouchDB and possible ones we add into PouchDB should go much smoother.

During this sprint, occasionally conversations would veer into discussing how we would receive the data from an mrs server and what kind of format the data would be. But after discussing it among ourselves, a helpful diagram drawn up by our team mate Connor showing our role in the overall project and we decided to only worry about our task, offline storage, and nothing else. So we are going to focus completely on fleshing out the service that will handle offline storage tasks using PouchDB. With a narrowing of possible tasks, the division of work for the next step should be very clear.

I feel like it took a bit, but we cleared another hurdle. After this we should speed up next sprint, and hopefully have a completed service that can handle offline storage and a pull request to the master ng2-amrs project by the end of next sprint.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

“Dig Deeper” is a pattern that I wanted to apply before I’d read about it. Ever since I started taking computer science courses past the 101 level, I’ve had the persistent nagging awareness that the knowledge I’m gaining is superficial, and there is so much more to be understood. I can feel the difference between knowing how to solve a problem and knowing why the solution is the correct one or the best option within the context of the problem. While deep understanding is a goal for its own sake for me, the writers present this as a goal because of the many problems that arise from only having a shallow understanding: being unable to fix subtle bugs, difficulty maintaining your own code, not realizing a problem you’re trying to solve has a well-known solution or is impossible to solve, and people thinking you’ve misled them about what skills you have. In addition, the lack of awareness of how little you know generates problems of its own.

To gain a deeper understanding of the technologies you use, the writers suggest reading specifications and learning from the original sources to see how the ideas came about.

I subconsciously understood this second method was important. My initial intention in studying computer science was to learn the entire history of computers as a way of discovering why things are the way they are now. I felt like I wouldn’t truly understand until I did that. Additionally, I also heard from several sources while learning C that The C Programming Language, the book co-written by the language’s designer in order to introduce it, is still the best resource there is.

The writers warn that if you apply this pattern regularly, you will naturally end up being given the most difficult assignments. This gives you the opportunity to both fail and succeed spectacularly. You will also likely be the one everyone turns to for code magic when they can’t figure out what they’re doing wrong. They advise you to continue searching for opportunities to be the worst one on a team.

This pattern is probably going to be the one that influences me the most, because it gives so many specific examples to look up of resources that lead to deeper understanding. I’m going to immediately go and apply this pattern, because I’ve been wanting to dig deeper in order to better understand the medical app we’re working on in the Software Development Capstone. Roy Fielding’s PhD thesis on REST sounds promising.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.