Category Archives: Blog

Expose Your Ignorance Pattern

For this week’s apprenticeship pattern, I did a reading on “Expose Your Ignorance”. A summary of “Expose Your Ignorance” is simply about how you may be unfamiliar with some technologies that are required to do a job and your manager and team members are looking to you to complete the job. At this point you already landed the position at the company but now, you’re required to do a task that requires certain technology like a specific language you’re not proficient in. To counter this, you must show them that learning new technology or anything is part of the process of getting a job done. In this pattern it mentions about how you should be honest and speak the truth to your clients and team members. This would allow them to be reassured even if you do not know the technology right away. If you’re able to show them that you’re learning and progressing, it will build trust and your reputation will be built upon that. Not only that but ask questions. Even though there’s already a presumption that you already know certain things since you’ve been hired, it will never hurt to ask since this is the most direct way in getting a task done and learning. The whole point to this is, to not be afraid of learning and let your team know that you’re learning.

My initial reaction to this pattern is similar to those of the other patterns where I can relate to it. In my capstone class, I am constantly being exposed to new stuff that I haven’t touched or barely learned from the other semesters, and I find myself always asking questions or looking things up on how to do a specific thing. What’s thought provoking in this pattern is how it mentions to not pretend what you know what you’re doing. I believe this is something a lot of people do, and it will negatively impact you more than anything. If you are honest with your manager and team members, they will get a better understanding about where things stand but will more than likely give you a chance to prove that you’re able to learn and do the work. Then if you were to pretend to know what you’re doing and give a horrible product. After reading this pattern, I felt more reassured that it was okay to ask questions and that it was okay if I didn’t know exactly everything. As long as I’m able to show I can learn and do the tasks properly and on a timely manner, I will be okay going into the professional world.

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

Sweep the Floor

The context of this pattern is that you are a new apprentice on a project. However, the problem is that you don’t know what your role is in this team. You don’t know how to contribute to the team and help them in any way necessary. The solution is to volunteer for simple, unglamorous, yet necessary tasks for the team. This way, you can earn team member’s trust, and you also get to show the team members how quality of work you can do. The tasks may be such as maintaining the build system, production support, responding to maintenance requests, bug fixing code review etc. The tasks can be anything, but it cannot have any high risks. Starting a core tasks and failing puts you into a bad side of a team, so it is better to start off with an easy tasks and actually finish it to have good relationship with everyone on the team. These short takes benefits the team, but it will also benefit your apprentice because such chores are often skipped in academic courses and by doing them you can fill in the gaps in your knowledge. After all, if no one sweeps the floor, then the glamorous work can’t be done because the team is hip-deep in dirt.

This pattern kind of reminded me of our group for the capstone project. When we first formed the group, I was assigned to the frontend part of the project. I was ready to do the first task from the GitLab issue board, but my main question was how can I convince the team that I can do this project together with the team and can actually make some contribution. In this computer science major, I feel as if I am always a step behind from everyone and have to add in extra effort to be on the same level as everyone else. So to show my skill, my first task was to connect two components and load one component only on click, which in my opinion is not an easy task but also not a hard task and I think I managed to do that, and the team seemed to love the way it turned out to be.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Craft over Art

This pattern starts off with a strong quote by Richard Stallman who states “I would describe programming as a craft, which is a kind of art, but not a fine art. Craft means making useful objects with perhaps decorative touches. Fine art means making thing purely for their beauty”. And this quote hit me right in the chest because I wished I had read this quote way earlier, around sophomore year or so. At that year, I was just trying to learn programming while also struggling. At that time, all I could do was some cool stuffs in my own personal computer’s terminal. There wasn’t any time when I thought I should build something that is useful and also could be used by others. All I had in my mind was how to make this code work so that it looks cool in my own terminal.

The context of this pattern is that I am being paid to build something that will solve a problem of a customer. However, the problem is that although there is a solution, my customer’s problem represents an opportunity to do something truly fantastic and is a chance to impress my colleagues with something beautiful. The solution starts as, the things we build for customer can be beautiful, but must be useful. This pattern is developing the ability to sacrifice beauty in favor of utility if and when it becomes necessary. The more useful a piece of software, the more important it is that the software be high quality. But quality takes time. You will have to work toward a suitable level of quality by repeatedly making trade-offs between beauty and utility. Ken Auer also states a really nice and meaningful quote, “Working on real problems for real people is what hones the craft, not just doing it for self-satisfaction”. The action is to do something useful rather than beautiful. This pattern reminds me of an app I made in operating system class with Professor Shruti Nagpal. For that class, our final project was to make something from what we learned in the class. Since my parents kept on asking me what is the current dollar rate compared to Nepali Rupees, I decided to make a currency converter app for them. The app may not be used by many people, but when I think of something I did useful, that’s all I could think of, and I don’t hear my parents asking for dollar rates anymore.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Retreat into competence

The context of this pattern is that when you realize how little you know, when you get out of your comfort zone and try new things. I think everyone who has done programming has gone through this problem. When you are writing code, nothing works on the first try then you try again the next day, and it still does not work the way you want it to be, at that time you feel like you don’t know anything at all. Then after a couple tries, the solution starts to come to you and everything starts to make sense, then you connect every idea and make it work. Just when you feel like you know everything and move to the new issue/project then the cycle repeats, once again you are introduced to the vast reaches of your ignorance, and you are overwhelmed.

The solution to such problem is to take a step back to jump two steps forward like a slingshot in carnivals. As the pattern says apprenticeship is a roller coaster ride as you thrive to learn new technologies, leveraging your knowledge and creativity to deliver value to your customers but if you compare yourself to someone who knows more than you or is an expert in the field then you will feel terror of perceiving just how little you know of things. A pattern like this is relevant to people (such as myself) who have pushed themselves beyond their ability, where they are constantly trying to learn new things, one after another, and there will be a time when this pattern kicks in. When such things happen, you retreat back to your competence to regain your composure. Take some time to build something that you already know how to build then use that experience to recognize how far you have come, then use that recognition to boost your confidence. For example, pick something self-contained that you know really well and reimplement it to remind yourself of your own capabilities. There is also a way to prevent from overwhelming, you can accept that his pattern is only a short time fix. You can set yourself a time limit. For example, I will refactor this code for half an hour before I jump into making another function or adding another feature.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Concrete Skills”

This apprenticeship describes how even though we may be knowledgeable software engineers, the knowledge we possess may not be enough to convince others to work with us. Instead, we need to show that we have the ability to apply this knowledge in the creation of software applications. Teams most of the time don’t have the luxury to hire someone who can’t contribute to their workload. It is up to us to convince them that we can demonstrate our skill practically in the workplace. It will be beneficial to us if we are able to display our skills in being able to build in various languages and frameworks. As new graduates, when being picked by hiring managers, they are taking a risk on us and our ability in our concrete skills is what should give them confidence in being able to contribute to the team on day one.

What I’ve taken from this is that I need to contribute more time into honing my concrete skills to be able to show others who take a risk on me that I am in practice and that I am capable of providing for my team instead of being a hinderance. Being able to show that I am able to use my understanding of the knowledge I already possess and translating that into other aspects of software engineering is what I should be striving to do. They also explain that what I’ve done in past shouldn’t be overlooked and that the softer skill that I have attained really are bigger than what they seem, and that these skills themselves also help contribute to being a better software engineer in the workplace.

This apprenticeship pattern reminds me that being able to be hired by a company is a testament to my ability and not just being a graduate. In order for companies to trust me, I need to show them that I can use my skills to help the team and not rely on others to help jump start my progression. This pattern also reminds me that the skills that I have acquired in the early parts of my life should not be downplayed. They do provide others that I am capable of many different things and that they can translate to many parts of my job at the workplace. I normally tend to shy away from my accomplishments from other jobs because they’re not software related, but after reading this pattern, it gives me more confidence in being able to embrace those previous accomplishments and use them to my advantage.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Naturalization Interview Confidence Environment “Sprint 1 Retrospective”

During our first sprint, our group was tasked with creating everything from scratch for this environment from the documentation to selecting the framework we were going to choose to proceed with. I was given the main tasks of assisting with the Read Me and trying to develop a working framework that was able to show IOS compatibility with React Native. The initial issue that we had was that most people in our group did not have a macbook and we needed to find a solution to developing on an ios device without the need of one. React eventually became our only solution and with it being able to project onto an ios device through expo and metro bundler. During this time we were able to assist one another achieve working react environment on everyone’s laptop.

Toward the end of our first sprint, we then proceeded to try and experiment with React where we stumbled upon another issue, and that was that we needed source code for everyone to work off of so that when merge our work together later on, it would work. Along with that, we now needed to think of the future so that students in the coming semesters would be able to work on that too. To be able to accomplish that, now we needed to create a synonymous docker file for everyone to use because many members of our group were working with different dependencies and now we needed to make it work so that not everyone has to go and download multiple things in order to get the code to work.

What worked well during our first sprint was our team chemistry and our ability to bounce ideas off one another as well as being able to assist each other with things we were stuck one. With a group that was able to communicate very well, we used class time to really try and move past any confusion regarding our project. It was also nice that no one judged one another and that we were able to openly express our ideas without any worries.

There was one thing that we lacked as a team the most and that was a sense of direction and urgency from time to time. Since our first sprint was primarily focused around picking the proper framework and most of the basic things of setting up our environment, it felt as though sometimes people didn’t know what to do due to the lack of work. I also believe that because this project was so new and no one was too sure about how things were supposed to go that maybe we were more worried about what we could achieve instead of what we couldn’t.

Individually, I felt as though I could have don’t more to put myself into contributing to things. There were times everyone was assigning things to themselves and I kind of put the groups priorities first instead of mine, and at times that felt as though I was not given enough to do. It also does feel like I am scared about trying to learn a new language and approach things I have not done before. I have the enthusiasm to go and try to learn things but also have the worry about possibly letting my team or myself down, and that might be a reason why I have not stepped up as much as I should.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Retrospective 1

When I saw the assigned group for the project, I had no idea who the people were. I saw the familiar faces, but did not know anyone’s name. On the first day of us seeing each other, we had a good greeting, even though we were missing two people. That day we all just talked about our repository, discord, and how to access them. We also talked about who will be the scrum master, for the project. The day went smooth like a butter.

On to the next week, all 6 of us were there and our scrum master (Vien) already had in his mind what to do for the project and how the planning should be, while all I did over the weekend was sleeping. Our scrum master divided the group into two, Frontend and Backend. I choose to be on the frontend team as I kind of wanted to learn more about frameworks such as Vue, React, or Angular. As I cloned the repository to my local machine, I had no idea what I was looking at, the docker images were wrong, the form for guest info did not open all the contents, the styling of the form was not responsive, and so on. Our (frontend team) first task was to refactor the frontend repo using vue.js and this is exactly what I wanted, I wanted to get more in depth with Vue.

On the third week, our scrum master already put up a lot of issues in the issue board, and I was so happy he did it. There was already a branch called refactor-branch which was created by our scrum master, and it had two components inside it. Frontend had 2 separate parts to complete. When a page reloads for the first time, it should only show an option for guest ID and nothing else, once the guest enters the ID, the rest of the form should display. Our main goal for that week was to display the rest of the form when the user clicks the submit button. One of my teammate refactored the guest login while the other teammate did the rest of the form in vue.js, and I connected both of their work/component in the main app.vue.

Fourth week, our side of the project were starting to look well, but there were still lots of work for us to do. Although I connected the two components together based on the button, it had its flaws, the form opened and closed once the user enters all 7 digits of their ID. To make it short and easy to understand, the button acted like a switch for a light. If a user clicks once, the form shows and when a user clicks again then the form hides plus the form stayed there even if a user removed their ID. It was a little success from my side, but in general, It looked lame, and I felt stupid. In order to fix that, I made little changes in the id-input component, and I was able to get the form to show only once and when a user removes even one digit from the search input then the form hides until he/she enter all 7 digits again. link.

5th week, Everything was going smooth. Teammates were adding small little important details here and there but at the end, who would want to use a form that has no style right? So I took a task to style the whole form which was left by previous students. And at the end I was able to get the form to look decent, although we might change the style or import one from the existing website.

At the end of the sprint, when my teammate displayed the form in a larger screen than my personal device, I noticed that the form stretches with the screen size. I managed to make form adjustable in phone screen, but I forgot about the screen that’s bigger than my computer, so I fixed it by setting a max width here.

Overall, I think our spring went well. The frontend side did a pretty good job and I when I looked over all the commits in the backend repositories, I noticed that they have been working even harder than the frontend team. In my opinion, I think it would be better to have only 2 people on the frontend and have 3 people for the backend while scrum master looks over all the infracture/review for the tasks. As for myself, I need to discuss more with my group about my work and share everything. With all due respect to my teammates, I don’t think we could have done this well without our scrum master (Vien) who have a good vision and I can tell that he is really putting all of his time to this project. Overall, I’m glad I’m working with this amazing team.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Unleash Your Enthusiasm”

What I have found interesting is about this apprenticeship pattern is that those who are enthusiastic about the work they do might not fit into their future team. It is a worrisome thing and that although there are ways to nurture your skills outside of work, most people tend to look at work as a way to work with others and expand their knowledge in software engineering. I had never thought that being enthusiastic could be detrimental to a team, but it makes sense that already existing teams probably do want to deliver on projects and their work instead of helping someone new out. It was nice to read that teams that are comfortable with themselves do beneficial from a fresh new mind and injecting them with excitement and questions will be beneficial to the team.

What I found most interesting when reading about this pattern is that as a soon to be graduate, we have the most excitement about the future of growing in our careers and that this pattern tells us that it is time in our careers to take the most risk and to speak our mind. We have very little to lose staring out and our ideas and passion will be more beneficial than detrimental to our team. As an apprentice, expressing ourselves is what we should be doing and it’s healthier for us to grow as a person that way. Instead of worrying about fitting into a future team, we should worry about being that spark that brings new ways of improving the team.

I as a person am very enthusiastic about everything I do. It does worry me that I might not fit into the team I work with in the future, but I hope that everything that I bring to the table is something that can help everyone. This pattern does make me thing about how important it is to work with my team and that hopefully my enthusiasm as a new graduate can help elevate my team to the next level. I also have experienced times where I have brought up ideas to engineers and then they shoot me down, but I had never thought about asking about how to improve my suggestion instead of just letting it go. This solution is a great way to figure out how to do better instead of thinking that your ideas are not good enough.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Concrete Skills Pattern

For this week’s apprenticeship pattern, I did a reading on “Concrete Skills”. Concrete skills are a pattern that I feel like I am currently experiencing. Concrete skills is about acquiring and maintaining skills that enables you to be ‘trusted’ by companies so they’re more likely to hire you. Concrete skills are supposed to reassure future team members that you are capable of doing the tasks that would be assigned by you and wouldn’t need to be babysat during the process. These types of skills are considered to be the basic of any programing language or knowledge. These are usually tested when you are being interviewed by current software engineers at a company that are simply just testing your knowledge. A great solution to anyone who has this problem is to work on side projects and casually review how basic functions work in your chosen language.

My initial reaction after reading this pattern is that it is a reflection of what I am currently experiencing. Since I have limited experience in the professional field of software engineering, I am currently requiring hiring managers “to take a leap of faith” in choosing me to work at their company, as the book says. The reading was quite interesting and very useful. Interesting because I can relate to what it is talking about and useful because it helps me with my current job hunt and figuring out ways to tackle this issue. Even before reading this pattern, I’ve been trying to practice more concrete skills and building side projects that will help me with the journey of becoming a software engineer.

The pattern has not changed the way how I view my profession because I already had an idea of how HR and the process works. The hard part of any job is getting selected for the interview process and for me, since I have no real type of internships, it is much harder. I do however have that I’ve worked in companies with good positions but they’re not entirely “software engineering” related. Therefore, I am constantly practicing my skills and working on side projects that I can showcase on my resume and be able to answer questions that are thrown at me if I were to get selected for an interview.

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

First Sprint Retrospective

Reflection on what worked well and didn’t work well
After having the Sprint Retrospective meeting with my group overall, I would say things went pretty well. The workflow of the group was simple and smooth, and both the frontend and backend development teams were able to make a lot of progress towards the project. Overall, we were able to get everything done besides 3 items on our issue board. The only issue we really had was our branches. While working on the project, we ended up making a lot of branches for different things we were working on. For example, in the backend we had a API branch, a jsdoc branch, and a test branch. Per the Product Owner, he said that this is fine, but we should be merging the branches to the main branch and delete the branches once they get deleted. This will prevent future errors as other developers work on this project and add more things to it.

Reflection on what changes could be made to improve as a team
The team worked pretty well. We divided the project up into two teams, backend and frontend. This allowed everyone to work where they were most comfortable with. From how the meeting went, everyone was able to communicate any problems they had with one another, and no one was ever afraid to ask questions when they needed help. Something that the team can improve on is probably be more vocal. Sometimes there may be a problem that a member has, and everyone is silent until one of the more vocal members speak up. It may be, because some of the members may not know the answer but overall, just being more vocal is what the team could improve on. Instead of saying “I’m done, here’s what I did”. Maybe they can elaborate on what they did, like if they had any problems that they had to fix on their own.

Reflection on what changes could be made to improve as an individual
From my perspective, the sprint went well. I was able to complete me task with very little difficulties. I will attach the work I did on the project at the end with a description. Since what I worked on was mostly what I learned from last semester it was relatively easy and straight forward. Only problem I had was when I had to figure out how to connect certain files. This was mostly because of how the previously team worked on the project. What I can improve on is probably be more active with other team members. What I mean by this is to give input on when they are having any issues or any type of problems.  

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