Revealing Ignorance

Hello, again fellow readers!

Today we will once again be continuing our journey into software apprenticeship patterns. From last week, we will continue on to the next pattern, Expose Your Ignorance.

This pattern is all about once you have gotten yourself onto a team where you can learn more from your fellow teammates, presumably in a job. The problem is that well… you are ignorant. You need to deliver and you have a lack of knowledge in whatever language or technology you need to be able to deliver.

The offered solution is fairly simple, ask questions and don’t be afraid to show that you are ignorant in a particular subject. You should recognize that it is human to want to appear competent and not appearing competent is not a bad thing. It is all part of the learning process. As a software craftsman, you need to know many different subjects and technologies. The pattern suggests that people who are uncomfortable with the learning process of appearing ignorant become experts instead. They seek out expertise in one particular field and never venture too far from it. Experts are important but the journey of a software craftsman is much longer and requires a broader scope of knowledge. You become an expert in one or several subjects along the way but that is not the ultimate goal. For a software craftsman, one of the most important skills is the ability to learn. To solve this problem the pattern suggests writing down a small list of thing you don’t really understand about your work and posting it in public view.

This pattern I find interesting. What I found most interesting was the distinction made between the software craftsman and the expert. The pattern admits that a software craftsman will likely become an expert in a few subjects but that is not the ultimate goal. The goal is not explained in the pattern (I’m sure it is explained at the beginning but I have forgotten it at time of writing) but the difference between the expert and the craftsman is that the expertise is not the goal. A craftsman goes further than becoming an expert and goes on to craft with the expertise of many under his belt where the expert gains expertise and then rests on his laurels. I do also appreciate the part where it states that by admitting ignorance it will increase your reputation greater than “fake it until you make it” will.

That’s it, for now, my fellow readers. Until next time!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Let’s Learn Some Concrete Skills

Hello, again my fellow readers!

This week we shall continue looking at Apprenticeship Patterns. I decided to skip over the Unleash Your Enthusiasm pattern and instead decided to talk about the Concrete Skills pattern this week instead.

The Concrete Skills pattern seeks to solve the problem of joining a team of craftsmen to further your learning opportunities. This could also be the all-important problem of getting a job. The problem keeps on going as you are too much of a risk as you may not be able to directly contribute anything to the team. You may not be able to even indirectly contribute.

The solution proposed is fairly self-explanatory. It’s right in the name of the pattern! Acquire concrete skills that allow you to demonstrate ability with relevant tools and technology. The pattern does suggest acquiring some skills that are geared more towards getting past HR and managers. I do like the proposed idea of “buzzword bingo” that the pattern mentions briefly. The rest of the concrete skills that you learn should be directed at showing your team that you are actually useful and that someone doesn’t need to look over your shoulder constantly to ensure you don’t mess up or break something. It goes on to make a good point. When faced with a hiring manager, they will ultimately be looking for someone who can actually contribute in some way on the first day. Having concrete skills is, as the pattern puts it, a way to meet them halfway. Then as you progress, you will have to rely on these concrete skills less and less. To learn what concrete skills to build, the pattern suggests looking at resumes of people whose skill you respect in the business. Identify some skills from the resume and work on them and of course, keep reviewing your own resume.

This is what drew me to talk about this pattern. It is directly relatable to me as I am in the job hunt as I am graduating soon. I found this entire pattern to be generally good advice for anyone in the software development field seeking a job. It also corroborates what a lot of people have given me advice for job hunting.

That’s all for this week. I wonder what pattern I will get to read about next?

Until next time readers!

 

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Sweep the Floor

For my last apprenticeship pattern blog post, I felt that the pattern Sweep the Floor was appropriate given where I currently am at in my career, given that I hope to be starting in the very near future. This pattern refers to the scenario in which you’re a new apprentice on a project or a new member of a team and you’re not sure what your place is in the team, so you want to contribute and earn the team’s trust. The solution to this is to volunteer for simple, necessary tasks that no one else wants to do and to make sure to do a great job with them. Of course, you want to make sure that you don’t end up only doing menial tasks that no one else wants to do and that you’re given more challenging assignments after proving yourself “worthy”.

As I said earlier, this pattern is probably one of the most applicable to me at the moment, because once I start I can see myself in almost the exact same scenario as described in the pattern. I always figured that most junior level roles start with you being assigned simple tasks like one-liner bug fixes to help you get acquainted with the code base, but I hadn’t considered that it would be a good idea to take on tasks like literally sweeping the floor in order to build confidence as a member of the team. Of course, I don’t entirely agree with consistently taking on tasks that aren’t relevant to what you want to work towards, but there’s merit in doing menial labor when you happen upon it. As long as you make sure to let it be known that you want to be challenged and not just be comfortable standing still working as the team’s gopher.

Overall, I would say that it’s very likely that I’ll end up using this pattern in the very near future, so hopefully I remember to avoid the negative consequences of applying it. In fact, I wouldn’t be surprised if this pattern would be useful for me anytime I happen to enter a new team, not just my first one.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Sprint 6 Retrospective

For the last sprint of the semester, I spent most of my time working on my part for our groups final presentation. There was one minor bug fix that I made involving an incorrect mapping for one of the product endpoints found from a user reported issue, but otherwise the rest of my time was spent on the presentation. This bug in particular could have easily been avoided if the project contained tests for each of the endpoints maybe by using a mock database. If, for example, we had a test that tested what would be an expected successful response, then the test would have failed for the given endpoint because it gave a 404 not found response instead.

For the presentation, since my task was separate from the main project for the food pantry, my section felt like it was a short, stand-alone presentation contained in a longer one. Looking back on what I did for the project, I definitely feel like it wasn’t too complicated and if I needed to do something similar now it wouldn’t take me nearly as long.

That being said, I think there are several major things that I should take away from this project. First of all, although the resources that I followed through were helpful in its creation, I wish that I had started from the ground up to understand how everything actually worked. It’s very easy to get something to do what you want from making minor changes to resources you’ve already found, but being able to actually understand how everything is working together and also being able to explain it well are much harder and take time. Another big takeaway is to make sure to have good tests and to make sure everything is still working properly by running through those tests after making any changes. The fact that the bug with the typo in one of the get mappings exists is proof that I hadn’t properly tested the code to make sure that everything was still working as intended when I pushed my code and created a pull request. I was very fortunate to have run into this issue at the end of the project because if I hadn’t then I might have gone on to make the same mistake in the future.

If anyone happens to work on the project in the future, the first thing they should definitely do is implement the automated semantic versioning that I neglected to do myself. It’ll save them a lot of headache if they make any changes because they won’t have to remember to update the version in multiple locations. Without a doubt, when I saw that issue, it was clear that it was poorly designed. There’s no reason for the current version of the project to be hard coded in multiple locations. Actually, when I pushed the changes for the endpoint bug fix, I ended up forgetting to update the version number and the pull request had already been merged, so definitely fix that first.

Link to project GitHub repository:
https://github.com/LibreFoodPantry/FoodKeeper-API

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

You Must Learn To Unlearn

Hello, again my fellow readers!

Last week we took a look at the beginner pattern, Your First Language. This week we will continue along the path to the next pattern, The White Belt.

As I have said, The White Belt is the next apprentice pattern after, Your First Language. This pattern is all about what to do after you have learned your first language and can strut your stuff with it. The problem The White Belt pattern is here to solve is when learning a second language becomes tiresome and tedious. Learning one language is great but, expanding your library is a must to become a software craftsman. What can happen, however, is slowdowns and stalling in learning. The solution to this is to adopt the mindset of a white belt. To quote the book, “Wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.” In other words, while you go about learning a new language, treat it as if it was brand new to you, even if you are learning something with familiar attributes. An excellent example is you have learned Java and now you are learning JavaScript. Both are fairly similar to each other and have overlapping ideas and methodology. Using the white belt philosophy, treat learning JavaScript as if it had no relation to Java. While this may seem counterintuitive (it still does to me),  the pattern claims that it will accelerate your learning. It will also allow you to discover new possibilities, as well as your mind, is open and without preconceived notions.

I understand where this pattern is coming from. I do get that an open mind can, and most likely will, lead to new possibilities. I agree with that. I suppose that my issue is that forgetting to accelerate learning is still something I find a bit backward. Looking at it, I must admit that I have not tried this method. Typically I find that making associations to things you do know is a good memory tactic and can speed up learning. It is entirely possible that the White Belt pattern will work for me. The only thing for it is to try it. I can legitimately say it doesn’t work without trying it for myself now can I?

Looks like I have some unlearning to do in my future.

Until next time readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Going Back To Square One

Good my fellow readers!

Today I will be discussing an individual Apprenticeship Pattern from the book, Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The pattern I would like to discuss today is naturally the first one, Your First Language, because where else is there to start but at the beginning?

The pattern starts by defining itself as a pattern for those who have surface knowledge of a couple of languages. It suggests that this particular pattern is for those who need to learn a language to solve a problem at work for example, or need to know a language for a job interview. It then launches into the solution, through execution of the pattern. To put it plainly the pattern is to pick a language and learn it. Having a problem to solve helps the process by giving you a goal to work towards and a drive to keep learning. It is also advised to take things slow and in small steps. It is also suggested to find a community and learn from its members as some methods or teachings may only be spread by word of mouth. It ends by reminding the reader to not get stuck with one language and to spread out into other languages.

I will admit, with this being the first pattern in the book I expected it to be for total beginners but it is aimed at just about everyone. What I find interesting about this pattern is that it seems to cater well to those who have never really picked up coding before or someone who, like myself, have had years of high school and college education in coding. I will admit that the amount I know about all the languages I have learned about is somewhat shallow. Some go deeper but many are probably not that far off from just surface knowledge. I might just try following this pattern after graduation. At first, I would have only recommended this pattern for only beginners who haven’t had formal schooling but after reconsidering, I think even those like myself who have had formal schooling can benefit from this pattern.

That’s all I have to draw from this first pattern and I hope to get more from future patterns. Until next time readers!

 

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

“Record What You learn”/”Share What You Learn”

This is the last blog post for Individual Apprenticeship Patterns, I want to end with “Record What You Learn”. Most of what we were talking about was learning and how to apply it to the real world. I thought this is important because I am also doing this in daily basic. I keep making same mistake, and I learn to avoid it slowly. There are issue I just need to more practice to avoid, but there are mistakes I could have learnt. The book suggests that some platform to write down. Ade uses two instances of the same wiki, one for his private thoughts and the other for stuff he wants to share with the world. That is the good idea, some from my mistakes I didn’t want lets other to know about it. But after this book I wouldn’t mind others to check on my mistakes. They could help me to fix it or at least I will learn from it.

By said that, I also want to connect this to the next pattern “Share What You Learn”. Like I mention above, we could become a journeyman, the ability to communicate effectively and bring other people up to speed quickly. We learn what need to be share and what shouldn’t. It does not matter what you take note for yourself. Before share to others, you need to think if that will have negative effect to them or even to the team. This could damage the relationship of the group. They also suggest that shared as blogpost about the lesson which is soft of what we are already been doing. In blogpost we also could share our solution and have conversation with other.

This is my final thought of the book. I think this book is good on the guideline on the ethics side of the industry. I also have honest advice from experience people. They gave short good example/advice that easy to ready. I am will read the rest of the patterns and keep this book with me.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

Expose your ignorance

Hello everyone and welcome back to another apprenticeship patterns blog post which is going to about expose your ignorance for CS 448. I think it’s an important pattern because I was in the same situation because I was uncomfortable with having the idea I didn’t know what I was doing and I didn’t want other people to think I don’t know what I do so I would stay quiet and try to guess what’s going on and it wasn’t working so well for me just like the article says. I now think it’s better to let people know what you are struggling on so that they can help you through your problems. When I first started my internship at an IT company, I first let everyone know that I didn’t know much or anything about IT, and everyone was very understandable and help me through it. I think if I would of stay quiet and act like I knew what I was doing it would of cause more harm than if I didn’t. I know that in ordered to learn more and grow, you must expose your weakness. I think this pattern does a good explaining that you should find your weakness and work on it and add more to the list as you go and don’t be a shame of it. I agree that you must show the process through your journey for the people that depend on you to know your stuff because if you don’t then you would show no promise. It’s also important to build a strong relationship with people as you are in your journey. All in all, I think this pattern was important because it highlights most of the stuff that should make you successful when on a journey to be a craftsman. I don’t disagree with anything in this article because most of the stuff that it goes, I try to follow every day because its good advice which I hear from successful people. I think it’s important to honest with your self and knows that you still learning and everyone doesn’t know everything and everyone is still learning

From the blog CS@Worcester – Phan's CS by phancs and used with permission of the author. All other rights reserved by the author.

Sprint 6

This week wraps up sprint number six, as well as the semester. This is our last sprint before the semester ends. Some of us, this is out last semester in undergraduate. Many of us will be graduating after this sprint ends. This sprint for our team was nothing entirely too fancy, it was more of a wrap up. Since we realized we were running short on time, and with a presentation of our final project looming just around the corner, we decided it would be best to stop the pipeline of taking in new tasks to work on. I was able to take on one small task in the end, just before we put a halt on work. This task was to add an optional field for gender into the intake form. This was a rather simple addition as I was able to reuse most of the HTML from another part of the form. The majority of the scratch work was done in the Customer.ts and the Customer-form.component.ts classes. In the customer class I had to add gender as an instance variable so that our customer constructor would know that it needs gender as an argument (needing it is specifically for testing purposes, the actual prompt is optional, per request of the food pantry owners). I then had to go to the customer.form.component class and add an array of options for gender, as this prompt would be a pulldown menu option. I was able to create an array of gender options called gender which had the values of male, female, other, or prefer not to say. This way there are enough options to cover the spectrum while also being able to keep the question entirely optional. Once I did this I had to add the gender paramaters into the Customer objects so that it would build the customer correctly. This was the easy part! The hard part comes next. Branches, and pull requests. I was easily able to check out a branch in our repository to get my issues and commits tracked on github. The hard part is the pull request. With the initial pull request, there are many conflicts to be resolved. This is expected, because you’re comparing an old file to a new file that has deletions and insertions, and code moved around. This is typically an easy fix as you can just go in text editor in github and remove the conflicts by hand and recommit the changes right on github. I have done the old fashioned way of running git commands in terminal to fix conflicts, and I find the in-browser option to be the more efficient and easier solution (if it allows, sometimes it isn’t as simple as removing a few lines of erroneous content on github). What happened next is the funny part. In the time I opened my pull request, notified my professor, and resolved conflicts, my professor merged another open request on our repository. Now I was getting no errors (because I had not refreshed the page) but my pull request would not merge. My professor and I were looking specifically at the customer constructor and were wondering why his master version had 18 variables and mine only had 14. After thinking about it for a while, I decided to pull from the master branch then recommit my branch, again fixing all the conflict resolutions. This appeared to do the trick, because I was missing the information from the merge that occurred while I was trying to get my branch merged. This goes to show you that communication is imperative on github and in teams of multiple developers working in the same place. Knowing this would have turned my 5 minutes of code and 45 minutes of trying to merge onto github into 5 minutes of code, a simple merge, and a new task. In the period of time between putting a stop to work and our final presentation, we as a team worked on our final presentation slideshow. We did this as a requirement from our professor, but also as a way to recap all that we have accomplished this semester. Looking back, it has been a fun semester getting to work on a project from scratch and seeing how far we could get. I hope the next food pantry teams have a good starting point, and will continue to do great things with the software.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

The White Belt

For this week’s blog I have decided to write about the chapter called “The White Belt” from out textbook. The context of this chapter is that you have developed a deep understanding of your first language but have plateaued and you are rather comfortable with that spot. I find this to be exactly where I am now. I have spent four years writing in Java a majority of the time. I would say that Java is the language I feel most comfortable in, and have the strongest understanding of how it works. Other languages that we have touched upon in my college career such as C and typescript/javascript, I am not as comfortable in because of this lack of depth of knowledge in these languages. This leads us to the problem portion of the chapter, which is that we have problems gaining knowledge of new things when we are coming from a position of comfort. The book points out a fear of personal development coming to a halt, and I think that rings true with me. I am afraid that once I leave college I will not learn as much as I need/want to. I am afraid of being a “one trick pony” with Java. What if my job requires me to code in C? C++? Any other language? I feel right now in this minute that if this were the case, I would be able to get by, but just barely and not very comfortably. And that is a feeling I do not want to have every Monday through Friday in my career! So how do we fix this issue of complacency? The book starts off the solution with a quote from Star Wars, which I thought was genius. The quote is, “You must unlearn what you have learned”. Now this doesn’t mean go and forget Java and all of its syntaxes and learn another language completely. This means unlearn your learning habits, keep your knowledge of Java but also learn to gain a knowledge of another language. Keep doing this, and soon enough you will be a master of programming. I find this solution to be rather comforting as I also find myself in this position of plateau quite often. I am hoping to continue my education of coding long after I leave college.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.