Category Archives: cswsu

Share What You Learn: Sharing is caring

While applying this pattern to my experience feels a little presumptuous, considering people do not “look to [me] as a source of knowledge”, I have tried to share what little knowledge I have as I gain in hopes of helping my classmates with any troubles they may have. Like Kindred Spirits before, I have had good luck attacking a new topic in our individual ways first then comparing notes and filling in the gaps in our knowledge others have covered. As well, this topic reminds me of Breakable Toys as well and my misunderstanding of it, where I concluded that writing a wiki may be a helpful personal learning tool but through the lens of this pattern, sharing it could provide a collective learning tool. While I have yet to go as far as creating that wiki, I have been willing to share any knowledge I have with my classmates.

I also got a great opportunity to brush up on our major’s most difficult subject and then test my knowledge of it by being a peer assisted learning mentor for Data Structures. I realized how much I missed the first time I took the class, and when explaining it I had to shed to convenient mental tools I used for more thorough methods that I could then share with the students. I remember specifically trying to explain how to rank program running times, without taking the derivative of the function that represented the run time; as many of the students had not, and likely would not, take calculus. By the end I did feel as though I was better acquainted with the material but felt sometimes like I needed to go deeper as I had difficulties explaining some concepts well.

Another time, I remember having to give a mock lecture to another student who missed a lecture. It really pushed my understanding of the material to the limit because I could recite what I had copied into my notebook but if he needed to ask a question I could have fallen apart had I not been confident in the material, or had a good understanding of it. The book says that you may feel that “someone more experienced [should] put themselves forward”. However, many people can feel intimidated by professionals and may not be willing to ask vital questions for fear of looking foolish; as opposed to the camaraderie of peers. I think that pushing ourselves to interrogate our own knowledge of material in the presences of peers offers an excellent opportunity for growth.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Dig Deeper: Finding the Marianas Trench of knowledge

This particular pattern is quite resonant with me, or at least the context section of it, considering it describes my entire academic experience in computer science fairly well. An excellent analogy would be a lake a mile wide but a foot deep; or at least it would be but a foot is very generous to the depth of my knowledge and a mile is delusional considering the limited scope of languages and tools I am familiar with. However, the sentiment expressed in this section still holds: “You learn only enough about any tool to get today’s job done”. I’m ‘you’. It is not for a lack of interest, at least not in all the subjects we have covered, that I do not go very deep into them – it’s exclusively a matter of time and mental resources. I have found that I have only had the time and energy to cover a subject as much as it takes to complete the require work or project associated it.

An example that comes to mind was last semester when working on both a REST API and Angular web front end – and by working on, I mean learning frustratedly as quickly as possible while working with both for the first time independently. There felt like so little time that I had to at one point neglect the JDBC features built into the Spring Initializer because I simply did not have the time to dig through the documentation. I had to instead use a less efficient and redundant method I knew well. Additionally, on the front-end side, I was able to brute force a lot of scalability because it was easier to use the limited knowledge I had to write ngOnInit and onResize methods to handle window sizing; as opposed to learning built in scalability tools or utilizing CSS more effectively.

To learn these methods would have taken a considerable amount of time that I simply did not have. Luckily this semester the pace at which the site is being built is much more manageable, as is the distribution of work amongst four people. So, with this time I hope to gain a better understanding of the tools and techniques I wish to utilize, before I do so. The pattern suggests writing a blog post, unfortunately this one does not fit that prompt. Speaking of which, I find the idea of going back to read a technological paper from 1976 to be a massive waste of time – but that’s just me. Regardless, and as always, I will seek a more reasonable middle ground between the pattern and what I find effective.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice: No, not that Dave Thomas

While this pattern is excellent advice, as the title suggests, I could not help but get distracted by the quotes and advice offered by Dave Thomas. Of course, it was nothing substantive that he was saying just that I could not get the Wendy’s founder, also Dave Thomas, out of my head. As for the actual substance of this particular section, it falls into the category of things I am trying to do more consistently in my academic life. Despite being kind of nerdy romanticized, and potentially misapplied, karate jargon; it is effective enough in conveying the idea of lessons, or more accurately patterns, that should be practiced often. Obviously, the linchpin of these lessons is that they are done in private where you can fail gracefully, a common concept in many of these patterns.

Regarding how I apply these patterns, I use a site called codewars where these exercises are also called kata but are done in a web IDE and can be checked for functionality within seconds. As well, all the solutions done by users can be searched, so one can “compare notes” with other users and see what, often insanely truncated, solutions others reached. This fulfills the dojo aspect of these coding exercises as well. If ever you were looking to apply a pattern most directly, this is it – and I hope other students will use this resource. While I don’t believe the site allows users to create their own kata like the pattern says, they do have a suggestion section in the forums. After long hours of honing your skills you could dream something up to really test yourself and others.

This pattern is related to a favorite of mind, Breakable Toys; and not unreasonably so, many of these exercise are incredibly difficult and I have found myself dropping them into my own IDE to finish off at my own pace apart from the web IDE. As mentioned previously, the school and work schedule I maintain makes it a little difficult to keep up with these exercises, or completely them consistently enough. However, I believe that have read this pattern, being set to graduate, and barreling towards my graduation and subsequent career, I do not want to neglect any practice I can get.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Use the Source: how to numb your mind faster than a lobotomy

Perhaps it’s just naturally a trait of mine, a coincidence growing up, or perhaps I more broadly reflect societies supposedly shrinking attention span; regardless of the cause, I have very little patience for reading documentation. Instead, I often like to open a sample project, usually the placeholder created by default, and see what happens when changing things around, or how information is passed between files. As such, I oftentimes find roundabout ways of completing tasks in a new language or framework. This results in less than ideal code, even if functioning, that does not follow best practice or any convention the language/framework may have. So therefore, the “Use the Source” spoke to a weakness I have in software development.

It states that one should choose a complex, and necessarily open source, project in the language you are hoping to learn to fork and pore over. In doing so, one can internalize as many of the lessons this code may have to teach, the ways experts write in this language, the “tricks of the trade” if you will; and, as a result, be inspired to apply these concepts in ones own project. This unfortunately, sounds terribly boring. It’s hard enough for me, and many other students I know, to pick apart our own code only months after writing it. I can’t imagine trying to parse years of work by developers with an incredible knowledge of their chosen language. This seems like a recipe for frustration. I could easily see a student not unlike myself throwing themselves at a new language in this fashion and coming away discouraged and maybe even completely overwhelmed; to the point where they may shy away from learning that language at all.

Instead, I would propose a healthier middle ground. I find that in messing with the code you can find little victories where your exploration paid off – victories that, for myself at least, keep me motivated. However, as mentioned previously, learning completely on ones own may waste valuable time and internalize bad or inefficient habits. As such, I think one should push their abilities as far as they can manage, then seek guidance from communities online. There exist thousands of YouTube tutorials and stack overflow threads where more than one solution is reached to nearly every problem; so, unlike the open source project, you can pick a solution that has a logic you understand best and can implement. I may have no patience to dig through years of documentation, but I don’t lack the patience to instead experiment and ultimately learn the language/framework.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

The Deep End: Taking off my floaters

The definition of many of the apprenticeship patterns in the book are all in their title, being fairly obvious or sharing language used in idioms or other expressions. However, despite this, our authors usually find a way to expand on them for at least a page or two – most often by sharing a relevant story. Which is why I was shocked at how brief this particular pattern was, just a handful of paragraphs and another for our story. The brevity of pattern however did not lessen its impact on me, and I have come away with a renewed confidence. As someone who needs structure in order to work effectively, I imagine the deep end would involve a great deal of work and specifically responsibility – which I respond to quite well also.

I had already determined to seek out an internship or entry level position outside of my home state. Further, I wanted to join a company where I, of course, could be actually hired but one that would truly test the limits of my skills. Ideally, I would want it to be an internship though, cause as much as I want to make this change in scenery, I’m still hesitant to get stuck someplace I’m miserable. I think the true test will not just be getting a position away from home but finding a place for myself in that new place and maybe even gaining the confidence to stay and accept a job at the company – in the case of an internship.

I did find one internship that states that they will make no “intern-work” and one should be expected to work as a peer with the rest of their fellow employees; and on a massively used and well-known mobile application no less. I jumped at the chance to apply for this position, and I am incredibly hopeful I get it, as it is the perfect storm of conditions I am hoping for. Enrique’s story is still a little too dramatic for me to imagine emulating, but I hope if the opportunity to work in another country even presents itself, I will have the confidence to take it.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Kindred Spirits: Programming inspired by Anne of Green Gables

When reading the kindred spirits apprenticeship pattern, I was immediately reminded of my first real programming class, CS140, wherein I met some of the friendly faces I would spend the next two years becoming a programmer with. A few of these faces were a part of my group in that class’s lab and with them we challenged each other in the subject and helped fill each other’s blind spots. While this is hardly unique, I’m sure, it exemplifies what the pattern is all about: finding peers who you can learn and grow with. Now with those two years nearly behind us and the end (of our education) is in sight, those same friends have been amazing resources.

As new learners, we tend to go in all different directions, not favoring any set method because we have yet to find the path of least resistance or best practices. Subsequently, we create puzzles pieces with our bits of knowledge that we all can combine to get a clear picture of a language, framework, et cetera. I have found as well, that what was often very useful was the ability to politely disagree – read: bicker like an old couple – with your peer and push back and forth on each other to really challenge one’s knowledge or understanding of something. It was through this back and forth that many of the solutions we were so desperately searching for came about; which is something the pattern even addresses, stating that it is imperative to avoid group think and challenge each other.

I remember distinctly have an erratic mass of code segments and illustrations of a particular data structure, the exact one I cannot remember, all over the board in the Science and Technology center study rooms. Data Structures, our major’s trial by fire, has crushed fledgling programmers of far greater skill than me. I can say with no doubt, that had it not been for these brain-storming sessions I would not have passed that class or even completely the projects thoroughly in the way that I eventually did. As I look forward to internships and even jobs after graduation, I hope to keep those around me who I have learned so much from and find new kindred spirits to take on this next chapter of my programming career.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Craft Over Art: or how I learned to stop worrying and love my ugly UI

As I mentioned last week, I have a tendency to try to make products out of projects; meaning I can’t just have something to tinker with for fun, it needs to essentially be a rough draft for the actual project I have to work on. In the same vein, I have another hang-up on wanting things to be clean and pretty to start. Now, of course, one should strive for well formatted code following best practices, but specifically for those projects with a user interface I try to go straight to a finished product from the start. As a result, the Craft Over Art Pattern was illuminating, bringing into focus where my priorities should lie especially in contrast to where they are currently.

In sum, this pattern emphasizes that you have been charged with creating a functioning product, not necessarily a pretty one. The line, “the things we build for customers can be beautiful, but must be useful” says it all. I realize in constantly polishing a project before its feature complete, I end up throwing away a lot of work spent on “dolling up” features or elements of the user interface that may change or not even be used. I even caught myself making the same mistake even on a personal project using a different web application language, where I did not even attempt to make any forms or methods that communicated to the backend, instead spending time adding libraries for user interface elements that look nice and animate well. While there is certainly a place for those things, this pattern helps one understand that is when you have all of the parts of your application finalized.

I should have learned this lesson last semester with my final project. I spent so much time fiddling with the color palette and page animations, that the content on those pages was barren, or poorly formatted. It is nice, I think, that my webpage looks and animates nicely, but when pages break upon reloading then it hardly matters. If there is constantly some expectation of failure with a project, then the font you choose is hardly relevant. I think that is what this pattern helped me realize most about this weakness of mine; utility is the most important aspect of software, everything else is so much fluff.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Breakable Joys: what I was missing in my breakable toys

As I picked through the list of Apprenticeship Patterns one of the earlier ones jumped out to me, as it seemed fairly obvious from the name what it was. Upon reading the description I was correct in this assumption and further I had experience with this particular pattern – even if outside of an apprenticeship. That description being a “toy system that [is] similar in toolset, but not in scope to the systems you build at work”. If you were to insert “school” instead of “work”, then I have built breakable toys for the same reason the book describes: to try and fail in private so that your successes can be applied to a real project using the same technologies, but your failures do not come at the expense of said project.

I have a sense already that many of the patterns I pick this semester will be those that I either have experience with or involve skills I feel insecure about. This being a pattern I feel familiar with I hoped to see if I was applying it correctly, and I wasn’t, at least not completely. First, the book stresses that a breakable toy should be like any real toy, fun. I think this is at least one hang up I have had with my own toys is that I try too hard to make them into potentially repurposable that I can use in whatever project I am training for. Instead, I think moving forward I will try first to make something fun, but overengineer it like the book says, such that I can gain as much experience possible from some silly little program.

Additionally, the book mentions making a little wiki as your toy, and this I had never thought of. Initially, I had read this as meaning thoroughly documenting the toy you are building. It makes perfect sense and follows logically one of the best points that has been made to me about learning, which is that the best way to do so is to teach. However, upon subsequent readings I realized they meant developing a wiki with your selected tools. While this certainly would help foster an understanding of yours selected tools, it would clash with the previous goal of being fun, at least in my mind. Instead, despite it being a misunderstanding, I think much could be gained from documenting one’s progress on a breakable toy. Considering I have a spike project to work on currently, I think I will apply these lessons as I begin.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

A series of relatively unconnected thoughts about the Apprenticeship Patterns readings

This blog contains mostly random thoughts as I did the reading. Nearly each paragraph is a new thought, but they all build to a whole that is effective strategies I hope to adopt or observations about the way the contents relate to my current place in school and work. Please take note as you read this.

I find it interesting that not only did they take the time to address what you should expect to do as an apprentice, but in outlining how your responsibilities change as a journeyman and eventually master they set you up for what you should expect from your mentors and what to strive for as a mentor. They do make a point of saying it is not their intention to write this book to make effective mentors, but I think despite their protestations it does provide a decent lens for the breadth of experiences, however brief their descriptions may be. While I may still be hardly able to envision my life as an apprentice let alone something higher, I hope to remember at least some of these lessons.

As well, one portion stood out to me very specifically as in the process of writing internship applications I had a cover letter I was very confident in, but realized that I could come off as too confident in it and had not emphasized my willingness to learn and accept new techniques. As a result, I will be going back to revise that letter again.

Unsurprisingly, much of these introductions is spent telling you to get out of your comfort zone for a deeper learning experience, but this should be understood innately, so it feels redundant. However, one good idea was to pick up a lesser documented language and try to write the documentation on your own. You could even do this exercise with an already well-established language to solidify your knowledge of it. In fact, more than just languages this is a great idea for any subject, as the old adage goes: “the best way to learn is to teach”. I have found for myself that tutoring a class while here at school was an amazing refresher for the material that I had forgotten since I had taken it so long ago and I picked up new knowledge that I had missed previously.

One thing that did confuse me a little was these chapter’s seeming insistence on remaining a developer rather than moving on to a leadership position or some other “higher ranking” position. Or rather, the utility of this book to those who wish to remain in software development, which makes a little more sense. With the mention of difficulty in keeping or finding good developers, despite a deluge of mediocre ones, made me worried about proving I am worth hiring or having a team that is uninvested in the work or does not possess anything close to mastery over it.

I was particularly struck by the quote at the beginning of Chapter 6, as I have a lot of trouble finding personal motivation without the structure and reward of grading found in school. Therefore, the advice of keeping a reading list is very pertinent to me as perhaps one way of building my own internal mechanisms for remaining engaged in my field and becoming self-motivated.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Libre Food Pantry Impressions

Upon reading the Libre Food Pantry landing page I was very pleased with the vision and mission sections, as they express the better angels of a computer scientist’s nature. Often times, I get very discouraged by the field as it seems like while many people may just not care, so many more simply want to create and solve problems – but these creations are used to exploit other workers, or invade people’s privacy. “Big Tech”, like all things under capital, takes the creative energy of its workers and uses it to enrich itself at the cost of human dignity, and oftentimes, lives. In a just society, we would value much more the contributions of these open source contributors than the efforts made to perpetuate war and mass surveillance.

…or at least that what I would say BUT if I decided to go to any other tab from the overview and then back, the contents wouldn’t load correctly. Rest assured I will be supporting a bug report.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.