Category Archives: Blog

Apprenticeship Patterns “Confront Your Ignorance”

This apprenticeship pattern describes to us how after being able to expose your ignorance, you must now be able to confront it. Once we are able to find the gaps in our skillset, it is up to us to tackle those problems head on. Confronting your ignorance does not mean to learn in isolation because doing that encourages us to create a standard where hiding your failures is okay. What we need to remember is that learning in public is always beneficial for an apprentice and that is what helps us move onto our next step of becoming better software engineers. What we worry about is when exposing your ignorance you become dependent on others as well as just creating problems for others when you don’t know something. That is why confronting your ignorance helps bridge the gap from between exposing your ignorance to being able to actually contribute to projects because confronting it is the best way to fill in your gaps.

What I have been able to away from this is that just because we don’t know something does not mean we should just constantly depend on others. If we fail to understand how to do something, we need to be able to ask for help so that hopefully next time we can do it on our own. With every project we take on in the future, it is obvious that we will need help in order to continue onward. We need to not work in secret to hide our failures and to use our mentors and peers as resources so that we grow and fill in those holes we all so definitely have.

After reading this pattern, it helped my reflect on a time where I created a Java application for work that would scan RFID badges of employees. I was tasked with this and initially had thought that if I could do it on my own I could prove I was capable and hardworking. In the end I took too long and did not have much to show for it, I was then partnered with someone who did have experience creating apps and in the end we were able to develop a functioning app. Pattern reminded me about this experience and that exposing and confronting my ignorance does not show that I’m weak, but that I want to grow as an apprentice.

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.

Learn How You Fail

The context of this pattern is that you cannot avoid failure. If you never failed, then that means you either avoided pushing at the boundaries of your abilities or has learned to overlook your own mistakes. The problem is that even though your learning skills have improved, your failures and weakness still remains the same. The solution is as follows, seek to identify the way in which you tend to fail and try to resolve them. Accept that there will be some things that you are not good at, or that would require a disproportionate investment of time and effort in order to make a small improvement.

Now for the action part, this is what I liked the most about the pattern. In the programming language of your choice, use a simple text editor to write an implementation of binary search in one sitting. Do not compile or run it. Write all the tests that you think are needed to verify your code you just implemented. Now, go back and re-read your code and find all the errors you think you made, keep doing that until you are satisfied with the code. Make sure you give in your 100% knowledge to it. Then, finally, try to compile and run it. Before you fix all the errors, look over them and try to understand how you could have avoided such error in the first place.

For me, this pattern was really helpful. I wish I had known about this pattern when I was taking a data structure and algorithm analysis class because I really had rough in those classes. I should have done this action part for all the topics in those classes. Such as, post order tree or pre-order tree from data structures or Dijkstra’s algorithm and divide and conquer from algorithm analysis class. I have been bad at so many stuffs now that if I do something wrong, it does not even faze me anymore. But one thing I did that I’m proud of is that, whatever I failed at doing, at the end I made sure I know how to do it the correct way. What I need to work on is to practice by implementing code in a simple text editor without any error warnings.

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 Patterns “Expose Your Ignorance”

This apprenticeship pattern describes to us how having the ability to identify our areas of ignorance and being able to reduce will be beneficial for us software apprentices in the future. There will be tremendous pressure on us in our future jobs to be able to work on and finish projects. They will expect us to be able to deliver software, and this is where we shouldn’t be ignorant of what we are not able to do because our lack of inexperience. This is where if we do not understand something, we should not be scared to reach out to ask questions and to learn about technologies and things that we do not understand. This itself reassures everyone of our ability to learn and by not pretending how to know how to do something, it exposes our ignorance to asking questions. What we need to understand is that as apprentices, there are many areas of our craft that we know nothing about, we can’t go around letting others believe that we know everything, but instead be able to reach out and ask questions without letting our pride get in the way.

What I’ve taken away from this is to not worry about questions because letting others think that you know how to do something and delivering something incorrect is even more of an issue. I think there is pride in being able to show others you can do things on your own without help, but being an apprentice means that you should be able to learn from others without your pride getting in the way.

This pattern has been helpful in letting me be able to understand how I am when I am given work to do in the real world. There have been instances where I have been given projects to work on at work, and I have tried to do things myself without help, this itself has led me to either taking too long on something or delivering work that I am not completely proud of. There have been other instances where I am completely unable to understand some things and asking others who understand it completely really helped elevate my understanding and learning of what I want. The ability to make uncomfortable situations more comfortable for me will be me exposing my ignorance.        

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.

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.