Showing posts from April, 2020

Study the Classics

The second pattern for this week Apprenticeship Pattern is “Study the Classics”. I think this one is pretty straight forward, as it states on point that reading and learning what is in the past is as essential as doing so with documents and books in the current generation, as it would allow ourselves to expose to problems that we might rarely see at the moment. The patterns start out with an extremely interesting problem that a lot of more experienced people in the field would likely to reference a concept from books and area that we might have now idea it exists, but they expect us to know it already, like any other self-respecting software developers. I have not experienced anything thing like this while working as an intern, but I can imagine that it does happens a lot to new developers in the field. The author explains the solution in a very simple way, which is to admit your ignorance, and ask about the concept, how it works, where do they reference it from and add it to our

Concrete Skills

The first pattern in the Apprenticeship Pattern that I read for this week is Concrete Skills. The pattern pretty much talks about skills that are required to be focus on when an apprentice software developer like us start our career. It also lays out a concept, which is to have knowledge about it, does not mean that we can successfully apply it to create a piece of software, and I think that this is crucial to remember. The pattern starts off by posing a really interesting problem that I think a lot of people, even veteran, are facing I would say, which is having a team, or a company that is not willing to hire someone that will, for sure, not able to not make any contribution to the project, whether it is direct or indirect, and this I think would take away the potential for an individual to learn and maybe even progress himself/herself in the field if it happens to them constantly. As the author starts to explain the solution, which is to acquire and maintain concrete skills, w

Confront Your Ignorance

For this week, now that I have read through “Expose Your Ignorance” in the Apprenticeship Patterns, I continue on to read through “Confront Your Ignorance”, as they seem to go hand in hand with each other. To sum up this chapter, it mostly talks about the advantages and disadvantages when taking action to fill up our knowledge once we identified the gap. The problem posted for this chapter is that while we have a lot of tools and techniques available out there that we can get our hands on, a lot of developers like us do not know where to start and a lot of common things that people know, we are expected to have those knowledge when we start working. I feel like this is the exact current state of a lot of new people who just got into the field and this chapter seems to be important to know about when we get started. The solution that the author presented, which is picking one skill, tool, or technique to actively learn about it, caught me off guard as I would never imagine it to b

Expose Your Ignorance

For this week, I continued reading the Apprenticeship Pattern and the first one that I got into  is “Expose Your Ignorance”. To simply explain this pattern, it encourages the readers to basically no being afraid of feeling ignorance and stupid when asking about what we don’t know. The problem of this chapter is presented with an example of a work environment that requires the developer to be familiar with required with technologies, but we simply just don’t have any idea how to use it. I like how the author says that it happens to everyone because it is true that people can’t know everything and this would let the readers know that it is common, furthermore encourage them to not be afraid and expose their ignorance. With the question of how should one exposing himself/herself to be the most effective, the author gave us one simple solution, which is to show other people that you might not know about it, but you are willing to learn how to do it during the process of delivering sof

Reflect as you work

For this week Apprenticeship Pattern, I chose to read about “Reflect As You Work”. When I read the title, my first thought is that this habit is pretty necessary, but it should not be too hard to have a chapter dedicated to it and turns out I was entirely wrong about it. The pattern starts with putting out the question of whenever a developer can consider themselves as “experienced” and how would that process be in order to reach that destination. The author then went straight to the point to explain how just reflecting our own work would be a best way for us to gain more experience. He explains several techniques like making a Personal Practice Map, which would involve writing down all the practices that we do during the development process and share with others, and mimic what they do in order to be better in the field. I think this particular technique would greatly help a lot of new developers in the field who does not know what to expect when developing and would end up doing wh

Sprint 2 Retrospective

At the beginning of this week, we finally reached the end of our second sprint, once a again, completing the back end for the LibreFoodPantry Approve module. My thought on this sprint is that our team did fall behind quite a bit on the goals we set out to finish at the beginning of the sprint due to the fact that we ran into much more problem than we expected and we don't really have much time to meet up with each other like the last one. Nevertheless, we were still able to achieve a decent amount of goal and almost reach the point to be deployable as a product for just the back end. List of what I accomplished during the last sprint: - Successfully implemented CI/CD in every main repositories and get it up and running to check for merge requests build ( ApproveGuestService ,  isApprovedWebUI ,  ApproveGuestWebUI ) - Adding all the required endpoints for the REST API system and set it out as a base for the front end to access data ( ApproveBetween , getGuestInfo , app

Breakable Toys

In this apprentice pattern, I took a look at "Breakable Toys."  I think this chapter is really interesting since it encourages developers to gain as much experience as possible through failures within a field that only a small gap for error. The pattern first presented the contradiction where developers are not allowed to make much mistakes, but those mistakes are the one that teach us the most in order to be better. The author moved on to present a simplest solution, which is to create our own safe space to experiment with new technologies by doing personal projects. I think this is a must do for a lot of developers who wants to improve themselves as it not only gain experience through making a lot of trials and errors, it can act as some kind of record to show employer that we are competent at this particular skill, technology, or language. Then the author talks about the main thing of this pattern, which is “breakable toys.” The term sounds confusing at first, but it se