Kindred Spirits

The apprenticeship pattern I chose this week is “Kindred Spirits”. According to this pattern, you may find yourself in a workplace that does not encourage software craftsmanship. In the absence of a mentor, you should find like-minded people who are also looking to become software craftsmen. Unlike mentors who are people you aspire to be like, peers are people you can feel more comfortable with. You can exchange ideas without feeling pressured like you might with a mentor. It is important to remember though that you should not just follow the crowd. It is important to think for yourself.

As a computer science student, I have the good fortune of being surrounded by kindred spirits. Most of my peers are of a similar experience level to me. Because we are all in the same classes, we are all learning the same language and doing the same assignments. It gives me so many other people I can bounce ideas off.

The author also discussed the difference between mentors and kindred spirits, and I think that difference is really highlighted when you are a student. It is often intimidating to ask professors for help or ask for their opinion. Sometimes when a professor tells you something or gives you a suggestion, you feel like that is the only way you can do something. With other students you are not as afraid to ask questions, especially if you are friends with each other. You are also able to take advice from them without feeling like that is the only way a problem can be solved.

Under the “Action” section the author discusses finding communities to join based on the languages you know or the tools you use. This is another benefit of being a student. Groups like the computer science club offer an in-person community to be a member of. It might be a bit harder to find a group after graduating but it is still do-able – especially with social media. If you cannot find an in-person group to join there will always be a discord server to join. You could even organize your own group easily using social media like the author says to do.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Unleash Your Enthusiasm

The key focus of this design pattern is the situation in which you have more enthusiasm for software development then the rest of your colleagues. Due to this, you end up holding back to fit with the group. I have a few experiences related to both sides of this. While I’ve never partaken in a software job, I have taken part in software courses. There have been plenty of times when I’m in a group project and the topic is so interesting to me I can just get to town and code almost everything. I guess rather than having it hold me back, I end up usually embracing it.

Then there are situations similar to that which I’m in now. It isn’t precisely a mirror for the apprenticeship pattern, but it’s pretty close. I find that when I have other things I need to do are when I’m most passionate about other things. For example, I’ll most intensely want to theorize about physics when I have an assignment due; however, once I actually have free time, I’m mostly content just wasting my time playing video games. Over the last month, I’ve become fixated with Sea. I had been working on creating a Minecraft Server manager in Node.js for my friends and I, then I moved onto creating a way of backing up my playlists. Then I realized it’d probably be easiest to do it in Python, so I started rewriting the code. In that process, I fell in love with Python.

I had used it before and enjoyed it, but I was almost something of an elitist. It had no strict types, it was easy to write. I treated it as if it were a beginners language. So I never really took the time to learn it. I rewrote my code in Python and learned a lot of the joys of Python such as context managers, list/set/dict/string comprehension, etc. (I just need to figure out the SQL commands and maybe I’ll eventually finish it). I had always been aware of the fact that Python running in a single threaded interpreter will never be able to perform as well as something like C. C by itself has a lot of joy to write in. Every language has its own personality you get to learn. That said, C can be tedious to write in and to read. That began my quest to create Sea – a version of the C language with Python-like syntax. I have become passionate about designing what the ideal language would be. Something modular, with high and low level features, and is easy to write and debug. Sea is just the first step in that.

I have found that I can so easily spend six hours straight coding, debugging, and refactoring Sea code. I can then go to bed and while I’m trying to fall asleep or even while I’m dreaming, I’ll be making design decisions. Classes that are otherwise fine can seem boring by comparison. Being able to just create something functional that has a clear use case feels great. At least sometimes, it can be really easy to share that enthusiasm with other students and it overall helps all of us.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

The explicit context of this pattern is that you’re a developer on payroll and you have been tasked with successfully delivering an artifact of software to your employer but unfortunately you have not previously developed software with some requisite technology for the project ahead of you. The solution prescribed in this Apprenticeship Pattern is a bold one that leans on previous rapport with your superiors; it insists on radical honesty where one admits that they do not presently know all of the information necessary to deliver on the project and to appeal to their previously established competency and ability to learn new technologies.

What I find most elegant about this approach is not only the ability to tailor current expectations using honesty but also the renewability inherent in this approach:

“In this way, your reputation will be built upon your learning ability rather than what you already know.”

The implication there is that if you stick the landing on delivering the necessary code, you will have created an evergreen approach to setting expectations and earned yourself the reputation of being not somebody who is valued for their finite pool of knowledge but rather their ability to tap into an infinite pool of knowledge. The authors cite Carol Dweck’s work, particularly how the need to appear competent is a mindset (no pun intended) that has proliferated throughout industrialized societies and is hard to break through. They insist that, while this embarrassment may be hard to overcome at first, your peers will have to notice your rapid progress and moreover they may find that by you forcing the issue they may have new realizations about their intelligence; after all people like to solve problems and feel intelligent.

I enjoyed the juxtaposition the authors make between those who become experts as a result of the perhaps not being as inquisitive or less confrontational with their inadequacies and so-called craftsmanship-seekers who become experts just by virtue of interest. While the first group may not be as ambitious or aggressive in their pursuit of knowledge there is no need to disparage this group and I appreciate that the authors did not decide to punch down where many other snobbier tech experts certainly would have.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Stubs vs. Mocks

            Having started to learn about stubs with relation to testing in class, I went to do some further research on the functionality and usefulness of this testing strategy. I found a great deal of articles comparing stubs with mocks and evaluating their differences. I haven’t heard of mock testing before, so this was interesting to look into. Turns out, it’s pretty similar to some work we did in class. I found this great article detailing the differences which also gives a simple, understandable example.

            The main difference in stubs vs mocks is that stubs are looking to see a certain behavior, while mocks are also setting an expectation and then verifying that expectation. This is demonstrated with the use of a couple examples. Stub methods are created in the example by not doing anything but printing out “_____ is working fine.” This is to check that the correct method is being called and in the proper context. On the other hand, a mock uses a third party library (Mockito) which creates a mock Mathematics object in a test setup. Then, still in setup, the expectation is set: when(maths.sub(2,1).thenReturn(1); This is just saying 2 – 1 = 1. And finally, this expectation is verified in the test with Assert.assertEquals(1, s.subNumbers(2,1)); If this explanation seems choppy, sorry, I tried to condense 44 lines of code down to just this. Anyways, the idea is that a mock object is made, expectations are set, and then they’re verified. So both stubs and mocks are useful kind of white-box-ish testing styles, but mocks seem to have a higher level of testability. This doesn’t mean they’re necessarily better or more useful, but they have their purpose too.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog Post #8

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.

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

Learn How You Fail

This week I read the section “Learn How You Fail” in chapter five of Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. This section focuses on the concept of learning from your mistakes by understanding your shortcomings. An example the authors use to illustrate this is writing an implementation of binary search and its tests in one sitting without compiling the code or running tests once. Once finished, compile the code and run the tests in order to find any mistakes you’ve made. Repeat this process until the code compiles and passes all the tests while also writing down notes on each iteration. These notes will act as an identifier to your personal shortcomings which will certainly be useful into the self-assessment that allows one to set realistic expectations and a direction to aim towards in self-development.

The concept of “Learn How You Fail” has a lot in common with “Expose Your Ignorance” like how they both promote self-improvement and emphasize examining one’s shortcomings. But the most important similarities among these is that they’re both concepts that center around learning from your failures. However, the key difference is that EYI is opening up yourself to failure while LHYF is learning from that failure. It’s just that both concepts complement each other in that one naturally leads to the other. Take for example that exposing your ignorance could very easily act as the direction needed for self-development similar to the notes in the “Learn How You Fail” example.

The idea of “Learn How You Fail” is also one that applies to many different contexts outside of software development. For example, before someone learns how to ride a bicycle, they’re likely to fall dozens of times. A saying I’ve encountered in everyday life is that mindlessly failing again and again will only get you so far, improving muscle memory and the like. A key aspect in learning effectively and quickly is knowing exactly what to improve on. That’s why I personally believe that a direction or a goal is incredibly important not only to this concept, but to learning as a whole.

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

Apprenticeship Patterns: How to Practice

Practicing is yet another aspect of software development that I have had issues with in the past. Personally, I find that whenever I bring myself to start some personal project with the goal being to practice programming I find that I simply have too much to do or what I am practicing feels too tailored to this specific practice program. Now that I am coming to the foreseeable end of my time in school, where these practice opportunities are essentially the focus, this issue has been weighing on my mind more and more. Thus, for this post chose to focus on the practice, practice, practice pattern.

Yet again I found myself really enjoying these patterns, as they felt very relatable. This was another insightful read, as I really did not have a set way to effectively practice in mind. I really enjoy the idea of katas that was brought up, which are simpler, but still somewhat challenging, exercises you repeat to try and hone a certain skill. In the case of programming, this can come in the form of working through some older books, as stated in the pattern. The idea of dodjos for programming also sounded enticing, as one issue I found with practicing on my own is a lack of feedback on what I produce. Solo practice is still effective to some extent, but I often find myself wondering if what I am doing is an effective way of solving the problem, or if anyone has devised a better one. This is the exact problem that a dojo addresses and is something I might have to take advantage of in the future!

This pattern has not really changed the way I view software development, at least in terms of practice. This is because I did not have a clear view of how to practice effectively in the first place. I have now been provided this new way of approaching practice that sounds both more engaging and effective than anything I could devise. I now understand that my practice session must involve short, challenging exercises and I must use others as a resource to compare my results and, ultimately, learn. I don’t really have much to disagree with but I did decide that I probably would not use those extremely old books for practice. As exciting as it would be to understand that older knowledge, I have more immediate things to learn.

Source: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s02.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Motivation

For this first blog post I chose a pattern that focuses on something I have struggled with on and off almost every semester, this being motivation. I am usually very gung-ho when beginning any sort of programming class, or personal project, but eventually I find that I just get completely buried. This can be for a variety of reasons, being other schoolwork or simply getting lost trying to solve increasingly more complex issues, but it happens consistently enough to be concerning. After reading this however, I do have some ideas for ways to try and cope with this should, or more accurately when, I get stuck in this rut once again.

Personally, I found this pattern to be very helpful, as it resonated quite well with me. I have been getting frustrated with a lot of my recent work, as it is all in relatively new languages I only have a vague grasp on, but I now realize what these are. As stated in the pattern, you have to set aside what you are comfortable with in order to grow, and these states of remaining in your comfort zone are classified as Golden Locks. I just have to understand that a part of the journey to becoming a master in this craft is resisting the urge to remain where I am, in terms of my knowledge. Beyond this, all of the examples used in the pattern felt very relevant and did a sufficient job at helping me relate to what the author was trying to convey.

I would certainly like to say that this pattern will have some effect on the way I think about software engineering. I have realized and acknowledge my issue with my motivation, being that I am simply on the road to mastery and must keep in mind that everything I am struggling through is just a part of that process. I cannot just retreat back into only really caring about Java, I have to continue working with these new languages as I encounter opportunities to learn them, otherwise my career, and most likely my passion, will stagnate. Maybe this is due to a lack of experience, but I did not find myself disagreeing with anything said in this pattern really, it was a good read!

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch03s03.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1 – Libre Food Pantry

The first sprint for the Libre Food Pantry software went very well for the most part. Since it was a spike sprint, it was mostly looking up tutorials, making sample projects, and brainstorming ideas.

What worked well for me was that I found a great tutorial on Node.js with Express which also shows you how to connect to and use a MongoDB database. This tutorial gave me a great foundation on how to run a server and handling HTTP requests. The tutorial had great explanations of why we are doing each thing step by step while other tutorials lack such explanations and just show you how to do whatever you are trying to do. From this tutorial I made a To-do list web application using Express, MongoDB, Ajax (Ajax code was provided from a source), Mongoose, and EJS(Embedded JavaScript) as practice for the Libre Food Pantry backend and also to make my skill/understanding more solid by practicing everything I learned from the tutorial. This also gave me a reference to look back on if I ever forget how to do a certain thing.

What did not go so well was my understanding of the project as a whole/how it all fits together. Studying the architecture of the project a few times did not do it for me. It took a while but learning Express, eventually asking my teammates about the technologies they are working with, how they fit in with the rest of the project and studying the architecture again after each new piece of knowledge finally helped it all click.

Some things my team and I could improve on would be to be more interactive on GitLab. By the time we made a repository to upload all of our progress, it was more than half way through the sprint. This meant that we could not review what our teammates were doing and have an understanding of our progress as a team. Also, our communication and teamwork could have improved as well. Instead of working on individual sample projects, we all should have worked together on a single sample project using everything that we learned. This would have been a better learning experience for us since that is what we will be doing eventually for the main project. We also could have had better communication with the product owner. I felt at times that not just me but my whole team was confused or stuck with what was wanted/expected from us. Towards the end of the sprint we eventually asked the product owner some important questions that really helped us move forward for the next sprint. Since we were mostly learning the foundation for new technologies this sprint it did not necessarily effect our productivity, but our motivation and confidence.

A change that I could make as an individual is to improve on communication. I felt that I did not have a good understanding of the technologies that my teammates were researching and how they intertwined with what I was working on. For example I did not understand what RabbitMQ was and what it had to do with the project when all I had to do was ask my teammate researching it to explain. Eventually towards the end of the sprint I did this and it helped my understanding of the project greatly.

Links:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Backend/NodeJSTutorial/NodeJSPractice – Repository where I uploaded files from each tutorial video.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Backend/TodoListApp – Repository holding files for the to-do list web application

https://www.youtube.com/playlist?list=PL4cUxeGkcC9gcy9lrvMJ75z9maRw4byYp – The tutorial I used for my sample to-do list app.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Sweep the Floor

            In the “Sweep the Floor” learning pattern of the Apprenticeship Patterns book focuses on the transition when joining a team. Being the newbie is not an easy task, especially when unsure of your skills, so finding your place and claiming suitable work can be a struggle at times. Since I will hopefully be joining a software development team in the coming years, or even next year as an intern, getting accustomed to working on a team and proving my value while not finding myself in too deep on work that I am not ready for will be a somewhat tricky line to toe. This pattern focuses just on that.

            The idea of sweeping the floor, while not meant to be taken literally, can be a literal task. It means to take the tasks that need to be done but no one wants to do. This can either be menial tasks or simply tasks that are painfully boring or something. Although not attractive, this can be a way to start making progress on a team and pay your dues. It can help gain the trust of the team if the tasks are done well, oftentimes because they can be important sub-tasks which free up the way for higher-level developers to make more meaningful progress, so they’re still quite important.

            Having the humility to take on tasks like this is not something I’m worried about; I do not come into the field with a large ego. I knew nothing about computer science before I started my major. I’m not afraid of having to build from the ground up. I’m actually quite eager to. Others’ evaluation of my work will be the most valuable to me, a concept which is alluded to in many other learning patterns within the book. I think this is a great idea and helps carve out a position on a team which can only stand to grow.

            It’s also important to consider the downsides that the pattern mentions as well. Becoming the one that other developers dump the meaningless/annoying tasks on is clearly not the goal, so making sure to not get complacent and expressing an eagerness without overstepping bounds is essential. Nevertheless, I love this idea and plan on going through with it once I join a software development team.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.