Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named “Perpetual Learning.” I was quite interested in the apprenticeship pattern called “Reflect as you work” once I read it. This pattern talks about how important it is to reflect on your own work and what you have learned in order to improve and progress as a computer science apprentice. All computer science apprentices should plan for a time to regularly review their work and see what areas they can improve in. It is also important to see what you accomplished and identify where you succeeded. You should always cherish those successes. “Reflect as you work” recommends you as an aspiring computer science major to draw a personal map for your own working habits and focus on the habits that have not changed in a while. Figure out if changing one habit would make you more productive and adopt that change.

To apply “Reflect as you work” to myself, I am going to make an analogy to playing video games again. No matter what video game I play, I always reflect on my actions, both when I succeed and fail. If one strategy fails, then I look back and try to identify points of failure and see how I can correct those mistakes. If my strategy succeeds, I celebrate that I’ve won (mentally in my head) and then look back and see if I can make the strategy better or make it more efficient. This is just a habit I’ve developed over years and years of playing video games. The same can be applied to being a software apprentice. If I fail to write working code, then I will try to identify the errors and try to correct them. If the code does work, then I will analyze it to see where it can be more efficient. In the future, I will always reflect as I work. As an example, look at this code:

int count;

count = 0;

while (count < 3){

System.out.println(count);

count = count + 1;

}

This code can be condensed down into:

int count = 0;

while (count < 3) {

    System.out.println(count++);

}

Which can be further condensed down to: 

for (int count = 0; count < 3; count++) {

    System.out.println(count);

}

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

The pattern I read for this week was “Sustainable Motivations”. It was about how to keep motivated through the good and bad times of your career. It goes over multiple motivations you may have for your job whether good or bad, like money or love. I found this pattern great because motivation is extremely important when it comes to the profession you will be spending your life working to master. It is something that comes to my mind all the time when I think about the future. Without motivation, something can go from your dream job to the worst one possible. We need motivation to get up in the morning and give it 110% wherever you work.

This pattern taught me that all your motivation does not need to come from big goals. Your motivation can also come from small goals along the way as well. Ideas like company activities for the workers who perform the best throughout the day, can even motivate people through the days that feel like a slog. This pattern caused me to really think of the ways I motivate myself. I try to motivate myself through the week by setting up activities I enjoy on the weekends, and giving myself more purpose to complete my work during the weekdays, so I can be free during my days off. I think my way is a great way to motivate yourself as not only does it bring more life to work, but it brings more life to yourself outside of work during the weekends.

I do not think I disagree with anything said in the pattern. I think it correctly goes over how you need motivation to continue working at your best for as long as possible. Without motivation, productivity goes down tremendously, and it leads to a bad product, so it is essential to have. Motivation is something that can be found in anything, and everyone has something that motivates them one way or another. I think everyone should read this pattern, and really try to think about what motivates them, and what will continue to motivate them when the going gets tough.

From the blog CS@Worcester – Anesti Blog&#039;s by Anesti Lara and used with permission of the author. All other rights reserved by the author.

The pattern I read for this week was “Craft over Art”. It was about how you should value the usefulness of an object you are creating over the beauty of it as the program can be beautiful, but it needs to be useful. I found this pattern very interesting to read as it is something that I really agree with. I have always seen usefulness as the true beauty, and have always valued something working over it looking the best. Would it be cool if the program was also nice to look at? Yeah, there is a sort of professional feeling to making a program that looks good and works, but you should never try to make code look better if it decreases its usefulness. There is always room for beauty, but not if it comes to the cost of the program itself.

The pattern did not cause me to change my way of thinking, but it did strengthen it, as I have always agreed with what is said in the pattern. To me, I always looked at the beauty of a program as something that can be worried about in the end, when the crafting of it is done first. When it is finished, then I can focus on making it look as neat and clean as possible without ruining its purpose. I have always been someone that wanted the better equipment no matter how it looked, so I think that has rubbed off on my programming.

Looking back at the pattern, it is hard for me to find something that I disagreed with. I agree with everything said in the pattern, and see it as common sense to me. I would rather make that 50 line game that is simple yet fun over the groundbreakingly beautiful unplayable game. I can see how some people can disagree with this though as some people value beauty over usability. An example of this is with kids, as some kids would rather have the worst Superman toy over the better Batman toy just because of looks. Other than those moments though, most people would agree that craft is over art.

From the blog CS@Worcester – Anesti Blog&#039;s by Anesti Lara and used with permission of the author. All other rights reserved by the author.

The blog I reviewed this week delves deeper on the topic of design smells and the classifications of some of them in different situations, some of which we had discussed in previous classes and some new ones that prove to be important to know in the long run. this article focus on design smells in the UI/UX side of programming and more specific to this side but still very much important.

The first discussed is “Documentation for Power users” which is the separate documentation used on portals to different sights when users click hyperlinks, or the different section on a Website or application. the issue comes from the formating and the flow of said website many look very cluttered and the flow of information is jumbled up. One specific example that is used for this smell is the Use of Microsoft Excel, the main focus being that it is a universally used application and thus has universal tools that the users disposal, the issue with such a great tool as without distinct tools being separated from the ones a user might not use in order to optimize the users experience it overwhelms them. this goes for all users as there is no case by case optimization, one solution brought up would be to dissect the application into separate products in order to better organize the UI for consumers in different situations, such as one made for educational use and one for corporate.

Another Smell that is discussed and closely relates to the previous is “Excessive Iconography”, this smell focuses on the use of unclear icons to display information in large loads, if we look at the example used in the blog of Xcode on Mac with many of the icons and labels out all on the same display to overwhelm the developer, making the tasks more difficult. the issue isn’t that the Labels or the Icons are not clear, but there are to many options and features present on the same screen. one way to combat this is to structure the application into smaller instances including all features that are connected together, allowing for clearer labeling and better overall experience for users. one personal example of this kind of structure I found was on Jira which structured its features according to what the user needed, allowing for a seemless UI and better experience. it did this but hiding features entirely that were not necessary and clearly labeling its tools.

Yodaiken, Aaron. “Ux Smells.” Medium, UX Collective, 7 Feb. 2017, https://medium.com/user-experience-design-1/ux-smells-fa971feef820.

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

This week’s Craftsmanship Pattern is another important one, breakable toys. This stands for the idea that experience is built upon failure just as much, if not more, than success. This idea is very good, as no one wants to fail, but failing is one of the best ways to learn, as if you are always successful, it is much more difficult to learn what does not work and what to avoid. The idea of never failing means you will never take any risks. To quote one of my favorite memes, “You didn’t grow. You didn’t improve. You took a shortcut and gained nothing. You experienced a hollow victory. Nothing was risked and nothing was gained.” While the above is pointed at cheating in a very difficult video game instead of “Gitting Gud” (intentional spelling) to pass a difficult task, I feel like the same idea applies here as well. It is important to learn what to do to succeed from what does not work, and what does work to continue using it.

To help with this growing, and similar to last weeks, it can be good to set up a private space where you can seek out this failure to learn from the experiences. For projects that you can fail on, try to build you own minor application, maybe a calendar or address book, for example. Things that are not too big, but still good enough to allow for failure without negatively impacting you. One highly recommended thing to do in the book is to create your own personal wiki, as you can use it to record what you learn. They are also nice since they can be simple, but still allows you to learn about things like HTTPS, REST, parsing, web design, etc. Sticking with this long enough will teach you about many things you many not have been exposed to otherwise, again creating an overall positive experience, because you will have some failure along the way, but how you overcame the failure is important. The book shows an email that Linus Torvalds saying that he is making a free OS based loosely off of minix, and those who know know where he went with this, and that is where we got Linux.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

This pattern is as clear as its tittle. Here’s the context given: you have realized that you’re not the first person to walk the path and that you are spending a lot of time exploring blind alleys. The problem is that you’re walking along a path with no idea of what’s around the next corner or how to prepare for it. You need help and guidance. The pattern doesn’t fail to recognize that our field is very young and therefore has few recognized masters. The solution is then to seek out those who have gone ahead of you and strive to learn from them.

I agree with the pattern because finding a mentor or someone that can supervise the work of an apprentice saves so much time and helps with building confidence. The pattern mentions how hard it is to find mentors sometimes and I can relate to that as I have found myself trying to find a mentor but it has always been hard. That being said, joining online forums, discord servers and being on “Tech” twitter has helped me make meaningful connections. I have come to understand that it is extremely important to find a community and put myself out there.

Another interesting fact they mentioned is that when trying to find mentors, an apprentice must remember that we’re all walking The Long Road and no one knows everything. It can be tempting to feel that your mentor must be a master because they know so much more than you do. That temptation must be resisted, because you do not want to become so disillusioned with your mentor’s inevitable weaknesses or blind spots that you feel you can no longer learn from someone who still has much to offer.

Something to remember is that your apprenticeship is unlikely to happen in isolation, and just as there will be people ahead of you, there will also be apprentices who have not yet reached your skill level. The other side of your search for mentors is that you must be willing to provide mentoring to those who seek it from you. Passing along what you have learned from your mentors is one of the ways in which you can begin the transition to journeyman status.

From the blog CS@Worcester – Delice&#039;s blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

The ‘dig deeper’ apprenticeship pattern imagines a scenario where you have familiarized yourself with a number of tools but only enough to be able to implement them into your own system. You do not take the time to properly engage with these tools, and you only ever learn enough about a tool to get through your own individual work. This superficial understanding of your tools can lead to issues, and you may have trouble recognizing and solving bugs that arises because of a given tool. The solution is to take the time to acquire a more in-depth understanding of these tools and technologies. This will give you a good foundation to build off as you learn other tools and will give you a more holistic understanding of the systems you work on. You should learn enough about the tools you used to be able to solve any issues, but you should not completely devote yourself to becoming a specialist in those tools.

I think this apprenticeship pattern is interesting. I am interested specifically in the Hoover and Oshineye recommendation to become familiar with debuggers that show you your running program, become familiar with wire-level debuggers, and be willing to read specifications. I knew that different types of debuggers exist, but I was never sure in what situations you would use them. I should follow this advice and do some in-depth research on at least the debuggers they mention. I also thought it was interesting that they recommend reading through specifications for tools; I do try to do this whenever I am introduced to a new tool.

I am definitely guilty of only learning a tool enough to use it in my own project, but I want to get better about understanding the tools I use. I think the advice in this apprenticeship pattern is very useful in this way, particularly the advice to obtain information about your tools from primary sources. I think being able to read through, parse, and fully understand specifications and defining theses would be beneficial to my career. I would feel a lot more confident working on a system with tools that I can comprehend the workings of. I think this is a good way to develop my skills and prepare for my future career.

From the blog CS@Worcester – Ciampa&#039;s Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern is all about expanding your knowledge about the tools you use and that if you find yourself in a situation where you are facing problems on the applications and different utilities that you have picked up over time has started to become a burden. This can be due to you using an unreliable source when learning about this product or just not going deep enough into the tool and only using what you needed at the time. This then can lead to troubles when you are put to the test or see a problem you have never faced before. The solution to this problem requires you to go beyond and start looking at the different nuances and inner workings of the programs you are working with.

Here this problem can be seen when you are perhaps interviewed and they ask you about projects that you have worked on. They then ask you about what you did and you can say that, but you don’t know exactly how it works all together, you coded some part of the backend but can’t exactly explain how that section functions. The background knowledge of the project is lacking in areas that could be problematic when you need to work in relation to that knowledge This is a problem and that you should instead take the initiative in understanding more about what you are working with to boost yourself and be prepared for a situation when this knowledge is required.

I myself could devote much more time into learning more about the tools I use and more about the projects I am working on. I could perhaps put some time into learning more on what is going on with the LibreFoodPantry and how the other groups are working to get a better idea of the situation. The job listings and internships out there are expecting more than just basic knowledge of the tools they list and use. There is much more with docker that I could be doing and figuring out issues that pop up from time to time if they are even fixable or not.

From the blog CS@Worcester – kbcoding by kennybui986 and used with permission of the author. All other rights reserved by the author.