For my final blog post pertaining to the apprenticeship patterns in the textbook, I decided to review the pattern entitled “Rubbing Elbows.” The situation that this pattern pertains to when the apprentice has almost plateaued and has been working on their own for projects. In this situation, the book explains that the apprentice will sometimes feel like they are missing things (like better ways of solving problems), but that they are not able to find these things on their own during their plateau. The reason I chose to review this specific pattern is because I can relate to it. On my free time outside of school, I have worked on projects on my own, and I know there are better ways to program what I am making but because I work on my own, I find it difficult to find those new and possibly better ways or working. The book’s solution to this problem is to find someone else to work with in order to learn more and have a different perspective on your projects/work. “Find ways to sit with another software developer and accomplish a hands-on task together, side-by-side. There are some things that can only be learned while you are sitting with another software developer to accomplish a shared objective.” I have actually done this before with a classmate while working on making iOS applications for fun, and it was an enormous help. Even if the person you are working closely with does not have a different solution to your problems, the added outside perspective proves to be not only helpful, but also necessary. I was especially excited when reviewing this pattern because I feel like I already am great at working with others, and the fact that that skill could be a good thing for my career is reassuring. The book describes how working with someone else could have many benefits even if it is only once a week. It helps keep you motivated and helps keep the other person motivated as well. If working with a certain person becomes not so motivating, the book explains that this does not mean you should give up, but perhaps you should think about working with someone else who could be even more motivating to collaborate with.
On the first exam for my Software Quality Assurance and Testing course, and in activities previous to it, Black-Box, Gray-Box, and White/Clear-Box Testing were important topics/definitions to thoroughly understand. Not only did we have to know the meanings of these terms, but we had to be able to compare them and know how those testing methods are used. White/Clear-Box Testing is when the tester knows the contents of a function or method. This comes with its advantages and disadvantages of course. The advantages are that it is very easy to navigate the complexity, get legible test cases, and makes debugging smoother. The disadvantages would include bias being used by the tester and possibly longer and more expensive testing in general. On the other hand, Black Box testing is quite the opposite. The tester is not able to view the inner workings of the function/method and is only able to test based on what inputs are given and what outputs are received. Although this seems counterintuitive for a testing method, it also has advantages and disadvantages that make it a viable option. The advantages would be that it would take less time and expenses to test and that it eliminates tester bias altogether. The disadvantages are that because the tester is not able to see the inner workings of the function or method, it makes it harder to debug, find complexity, and have easy to read test cases. The two methods are basically opposites. Lastly, Gray-Box Testing is somewhere in-between the two. The tester knows a little bit about the inner workings of methods and functions, but is not focused on them completely like in White/Clear-Box Testing. This makes all of the advantages and disadvantages even out more overall which could be good in some cases but could also not be a valid testing option in other cases. Before this semester, I actually had never even heard of these terms, and it was interesting to go through and research them for this post and for my course!
For my second to last apprenticeship pattern blog post review, I would like to talk about simply because of how close it hits to home with me is the pattern entitled “Draw Your Own Map” in the textbook readings. This pattern is based on the fact that throughout the lives of software developers, there will be many times in which jobs or opportunities will not quite fit what they are capable of or are even interested in doing. The main issue brought up in this chapter was that none of the career paths provided to young software developers are often fitting for them. The reason that I chose to review this specific pattern is because I believe it relates to me very deeply as I am worried that whatever direction I end up taking after college may not be right for me. I already have many different options and directions that I could take from here and the opportunities are almost more daunting than exciting at this point. I am worried I will make the wrong choice early on. The book tried to solve this problem by basically saying that I choose my own destiny. “Identify a logical but ambitious next step for your career. Understand that it’s not up to your employer, your career counselor, or your professors to give you a hand up.” Sometimes the guidance of others is not what is needed even if it is with good intentions, because more often than not, I should know what I like best. The book also explains that no matter what direction I want to choose, it is important for me to make sure to take the first step. Without the first step, the dominos will not start falling and there will be no momentum toward my goals. If others (such as employers) try choosing a path that is not right for me, I must reflect and make the decision to stay on the course that I personally see best fitting for me. Obviously, when working, I should complete my roles and not give up, but in the end, it is not wrong for me to change direction and even switch career opportunities for my own betterment if I feel I need to.
The second assignment I worked on in my Software Quality Assurance and Testing class combined what we learned about JUnit 5 testing and using Gradle to automatically run all the tests fast and easy. This assignment proved to be more difficult than I was expecting, but in the end, I got very good at it and learned what I needed to. Downloading Gradle in the first place was my initial issue, since it seemed much easier to get it with a Windows machine than my Mac. Some classmates were kind enough to assist me and let me know about a software called Homebrew that basically is able to download Gradle for me. This was so helpful, and it was installed in no time! The second thing that make this assignment more difficult was that the actual tests I had to write were much harder than my first assignment. It took a lot of debugging and testing over and over again to finally get all of the tests to pass correctly. For some reason, many of the errors I ran into were primarily because I have made silly mistakes like grammar or syntax faults. All the repeated testing and debugging made me so much better at writing the methods correctly. The last thing that I would like to reflect on from this assignment is something I should have covered in my previous blog post. It is that pushing my projects to GitLab has changed. Of course, it has not changed that much, but just slightly. Rather than using the command “git push origin master,” I now have to write “git push origin main.” This is not too big of a deal for me, but at first I did not understand what I was doing wrong because of my pushes not working. I believe all of these things together will be a big part of my first exam in this class, and because of that, I am happy I was able to briefly discuss them in this blog to get a little extra review on them before that date!
With the semester nearing its end, I do not have many more apprenticeship patterns to review on here. Because of this, I am trying to choose patterns that have the most relatability to me. For that reason, I chose to review the pattern in the book entitled Sustainable Motivations. It is all about developing your technical skills in order to maintain your ability to work well given different project goals and situations. The problem that I am trying to solve by learning this skill/pattern is the fact that this line of job is often rigorous, difficult, and stressful. I need to learn to love what I do and be good at what I do when I am not loving it. The book explains how there are many days, weeks, and months where my job will be extremely fun and enjoyable, but that there are also many times when it will be quite the opposite. The important thing is for me to keep moving and working through the not-so-good times and continue to stay motivated as much as I can throughout the process. The book has some great tips and examples of how to stay motivated during the harder times. First, I should be working hard to move up in the ladder of my jobs rather than just fulfilling my personal duties. This is especially apparent when I am not enjoying what I am working on and mainly working for the money aspect. The second example is when I could possibly want to quit and I decide to pull through and finish what I am working on. It proves valuable and exciting to finish things whether you liked the process or not. Lastly, the book shows that pulling through the tough and hard times will help your reputation as a worker and a programmer immensely and that in doing so, more opportunities with open up. This whole pattern resonates with me so much because of how ominous real life jobs feel to me at the moment. I know that if I follow those three examples/tips, I will not regret it! Bad times will happen, and pulling through will only help me grow.
After the first month of my final semester, my capstone course has proved to be an interesting experience so far. As much as we are working in groups to create a database dedicated for the food pantry, I believe we really are striving to strengthen our skills with using the SCRUM method of group work. Our first sprint went very well in my eyes. We have not gotten much done in terms of making the frontend and backend of our database, but we accomplished a lot when it came to getting tasks done that we chose to try to complete at the beginning of the sprint. Our team worked very well together and it seemed as though everyone was contributing heavily towards finishing our tasks quickly and completely. Personally, I thought I contributed a lot of research, work, and extra effort for the team to help everyone out. We decided to make me the team’s SCRUM Master which in all honesty did not force me to have much more responsibility at all, but it was helpful for me to learn from the product owner and relay back to the team. I tried keeping helpful information posted both on discord and on gitlab for the team and for myself. This proved very helpful. In the future (for later sprints and for in similar situations in real life), I believe we could have done a better job communicating outside of our class periods. It may have help our group get things done even smoother than how we already did if we had been running a better communication system. This however was not really anyone’s fault as we were still able to get most of our tasks done and because of the fact that everyone is taking a lot of classes right now and not just this one. On a personal note, I think it would have relieved some stress for me if I could have tried spacing my work for this group out throughout the week rather than getting things done in one or two sessions per week. This would have made it easier for me to communicate problems if I had had any and would have reflected better on my final completions at the end of the sprint. Again though, it is more difficult when I am taking other courses and not having this project as my main job or focus. The main issue that I think my group and I will run into for the next sprint is that we will have more tasks related to building the database now rather than the more learning and reviewing bases tasks we had in sprint one. Like I stated earlier, this sprint seems more like one in which we get familiarized with how the rest of the sprints will be done and how to work as a group with SCRUM. However, I think we picked up on what we needed to do very fast, and everyone seemed to have put in a lot of good work and dedication. Because of this, I know that even if the tasks in the next sprints become more difficult, we will still be able to get great work done and have a successful product in no time!
For the next apprenticeship pattern that I would like to discuss, my choice was to do the one in the text book entitled “The Deep End.” This pattern was similar to a previous pattern that I have discussed in that it relates to a time when a beginner in programming is preparing to enter the real world of job opportunities. In the other pattern, I learned ways in which I should try to show that I am qualified for a new job if I do not have much prior experience, if at all. A lot of times, employers are looking for candidates who show that they have the skills necessary for the position based on many things (primarily prior experience or certification), but sometimes what is needed is more than that. Sometimes what is needed is the willingness to try more than anything else. For this pattern, the book discussed how to motivate me to dive off the deep end and get the job I want not just the one I think I can handle. If my enthusiasm and my will to excel and learn at the job remains strong, I should not have to concern myself as heavily with how well equipped I am for the job in the first place. I purposely decided to review this pattern because of what is going on in my life right now. I have been setting up job interviews and phone calls recently to try to get jobs after I graduate. In most interviews I have had, my background has been an issue even if the employer does not seem to think so. I am thinking too much about whether I will be able to even do the job if I get it rather than trying to get it as best as I can and then seeing what I can accomplish from there. The book explains that the solution to this problem is to reach for that opportunity even if there is the possibility that it could lead to failure. It states that “waiting until you’re ready can become a recipe for never doing a thing. So when you’re offered a high-profile role or a difficult problem, grasp it with both hands. Growth only happens by taking on the scary jobs and doing things that stretch you.” My solution would be to do just that. I am going to try to get involved in the opportunities that I have been hesitant about pursuing. The risk of failure is often overemphasized and crippling to anyone who tries to find their opportunities especially in the beginning of their journeys. I need to stop weighing the risks so heavily and quite literally “dive into the deep end.”
The fourth pattern that I plan on discussing is titled “expose your ignorance” in the book. The reason I want to choose this pattern to learn next is because I believe that it relates to me one hundred percent of the time I am in school. The idea behind this pattern is that if you do not speak up when you are lost, you will inevitably hurt your learning process. Many people, including myself, get into the habit of not vocalizing questions and concerns for fear of being disruptive, time-wasting, and possibly getting even more confused. It is very easy to simply keep your head down and struggle through a course or project without getting everything you need out of it. Basically, in situations where you do not know what you are doing, protecting your pride is often a bad solution, and exposing your ignorance is likely your best option. The book does a great job explaining why this is and it has good examples of times where it is a needed apprenticeship pattern to pick up. Even in jobs, it is important to expose your ignorance. The easiest way is by asking questions. Not only will it help you learn faster and more, but it will also ensure that you are doing everything right and in the way that your employer expects you to get your work done. The book has other solutions for this as well. In fact, the main action that it tells you to carry out is to “write down a list of five things you really don’t understand about your work. Put that list where others can see it. Then get in the habit of refreshing this list as your work changes.” Personally, I feel like in my years of schooling I have not reached out enough with questions for fear that I would look like I do not know what I am doing. It is not going to get any easier for me when I try to get real jobs, so it is important for me to learn to put my ego aside and expose my ignorance in a way that will allow me to learn and get better everyday.
After completing my apprenticeship introduction blog post and two different patter reviews, I am excited to keep reviewing more. For the next pattern from the textbook that I have chosen to review, I chose the “concrete skills” pattern. The book describes a situation in which you are trying to work with a group or at a job in which you do not have a very strong background in yet. This is ofter one of the most inconvenient thing when looking for starter jobs. Most jobs want individuals who have a good background so they know you will be a good fit for the job. The book also supplies us with a great solution to this problem however. Basically, it states that you will have a better chance getting the job if you can prove that what you lack in background work, you make up for in your ability to learn quickly and work hard to learn new things on your free time as well. The more jobs and projects you can accomplish/work on, the better your portfolio and background becomes overtime. Eventually you will find it easier and easier to get where you want to get, and it all starts with your first several projects/jobs. This specific apprenticeship pattern resonated with me primarily because I personally do not have a great background yet and am trying to create a good one. The advice from this section was super powerful, and to be honest, this might be one of the most important concepts discussed in the entire textbook!
For my Computer Science Software Development Capstone course, we are reviewing the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. Before discussing different patterns themselves, I would like to review and discuss the introduction chapter and the smaller introductions to the first six chapters of the text. The entire beginning of the book attempts to explain and introduce us to what exactly we will be learning throughout the semester. It goes over what apprenticeship patterns are and where they came from. It tells us what exactly software craftsmanship is and what apprenticeship is. Lastly, it tries to answer the question “what next?” after learning these things. To start, the book makes it clear that there is no simple definition for software craftsmanship (at least how it is using it), and it tries defining it as a “community of practice united and defined by overlapping values.” To see those values, I would read page four and five in the text. Next, the book defines what it means to be an apprentice. It states for the most part that it is the state of looking for more efficient ways or better solutions including looking for better resources to help because anything being done could be being done faster or better. It defines apprenticeship as the state of learning the craft (in this case, software development). In the conclusion of chapter one, the book discusses where apprenticeship patterns even come from and what we should be doing with them. It claims they come from “many working systems that have used the same solution to solve similar problems.” Basically, after learning all of these patterns, I should be able to take what I have researched and mix and match the patterns where I see fit in real life as if I am the apprentice right now and the book is my tool for learning my craft. Before I conclude this blog entry, I would like to briefly discuss the introductions to the five chapters after this first one (especially since I will be reviewing patterns from them over the course of the rest of this semester). Chapters two through six will cover patterns ranging from self-assessing, resilience training, working patterns, working with others, perpetual learning, and constructing my curriculum, etc. I am extremely excited to get into my assessments of these different patterns and learning about my craft. I actually have researched a couple of the subjects covered in these chapters and it is incredibly valuable information for my future as a software developer. I look forward to reviewing at least eight (if not more) of the different patterns and sharing my experience learning them with anyone who will be reading these blog posts now or in the future!