In the chapter Emptying the Cup, I chose to write about the apprentice pattern Your First Language. This pattern discusses picking your first language and what practices to develop to enhance your understanding of it. This pattern stood out to me this week because I relate to the fact that I only really know one language, Java. I have dabbled in other languages like Python and Vue for other classes, but a majority of my college education was in Java. I have had worries looking at job applications where the employer requests that the individual that applies has knowledge of different languages such as C++. The section explains however that if an application calls for experience in a different language, then to create something in that language and learn, and build something that you can show off to employers.

The article explains that different languages have tools that can help individuals learn that specific language, such as Ruby having an interactive command-line tool irb. The pattern ensures that there are tools and help available for individuals in case they need a little extra push in learning a new language.

Another important point that the pattern points out is to ask an experienced individual in your life for help when struggling with a new language, but not to become completely dependent on that individual. Working through struggles on your own will ensure that you learn more throughout to process. I have had experiences like that through my education, where I have been stuck on an issue and I needed to lean on my professor to help out. Instead of just giving me the answer however, the professor would ask questions that would help guide me towards the solution. This is an effective mentorship trait.

This pattern really helped comfort me with the worries I had regarding job searching when I graduate. I want to be able to perform at my new job and become a helpful member of the team, and the worries of not being proficient in a certain language holding me back was hindering my confidence to achieve that. But the article reassured me that if a job asks for proficiency in a certain language, it’s just an excuse to mess around and learn in a new environment and adapt.

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

Greetings!

This week, I wanted to kick off with the pattern “Retreat Into Competence” from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye. 

Retreat Into Competence relates to scenarios when you realize how little you know or you’re facing a challenge that’s making you reflect back on your knowledge, and you feel overwhelmed. The solution to this is to give yourself a moment–or a little longer, and step back from the challenge you’re facing. Then, take some time to work on something you’re familiar with or know that you’re capable of doing. 

The pattern touches upon how you may feel the thrill of learning new technology along the way of your journey, and the satisfaction of delivering things to customers. And then, you meet more experienced people along the way who make you feel that you really know nothing, and you can also feel this way when there are fast-approaching deadlines and product issues. And sometimes, to deal with this, you need to go backwards to move forward again.

The book warns to not retreat too far back into what you’re comfortable with if you’re afraid of failure, because what you’re comfortable with may no longer be used in the future and the extent of what you know is very limited and you may need to face the consequences of that. Therefore, the book says to use this pattern only as a little pick-me-up, and not to use it for too long because it can be a double edged sword. For action, it’s suggested to pick up something you are well acquainted with and work with it once again. 

I find it interesting that I have utilized this pattern with my internship. When given a new task to code for something in a report, I often change the report template and form corresponding to that report. My biggest challenges come from changing the code in the report, so I sometimes find myself taking a break from that and moving to the template or changing the report form–tasks I find more simple that I have a better grasp on. I agree with the book that it is a short-term fix and should eventually move forward. I’ve recently realized how much I’ve learned from my internship when I took a step back to work on the form and template. It had been something that I had no idea how to handle not too long ago, and now it’s something I’m most comfortable changing. And that’s what made me feel so accomplished and happier to move onto the report code, knowing that I’ll eventually be able to consider the report code something not too difficult to handle. There wasn’t anything I disagreed with.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

In my last post discussing testing and QA development, I went into depth about a project I was working on last year. I was developing an app that was supposed to track one’s financial history. It was the first project I had ever worked on that gave me free liberty to do whatever I wanted. I explained that it took a lot of my time and I ran into a lot of issues regarding the organization of the code, for the most part, I was most concerned about making something that worked rather than making something that worked effectively. Recently, I read a blog from Thesoftarch discussing how to write object-orientated code effectively.

The blog “Simple & Effective Way to Write Object Oriented Code” basically explains that most developers, like me, will only look to write code to reach functional requirements and not advocate for the technical quality of the code. The blog post explains that writing code to be functional can be acceptable during initial releases but can slowly turn complex if not managed correctly. So, it is important to maintain quality so that in the long term we can avoid struggling with maintaining the application. Different ways of writing effective, approachable code include making it simple to read, easy to test/verify, and having a low cost of change. The blogger goes by explaining the three basic steps of writing effective and well-designed code.

First, they go on to say that writing is easy but writing effective code is not easy, especially when you don’t have an approach. There are many design principles that developers go through in order to design good code. This includes SOLID, DRY, Design to Interface, and many more.

The second step is Unit Testing, as explained in my last blog post, it’s important to ensure that the code written works as intended. it’s best to write unit tests every time a method or class is created instead of writing the unit tests all at once.

The third and final step is to refactor. Refactoring is an activity to improve the quality of code without affecting its behavior. Making this a habit will help “maintain the code in the long run without adding much effort or risk.” As the blogger puts it, the coder should be able to identify “smells” in the code, refactor code to remove the smell and fix unit tests. Smells are certain structures that indicate violations of fundamental principles and negatively impact quality.

While reading this blog I’ve been able to keep note of what I need to do and look out for when it comes to developing a program. If I had read these steps last year, I think I would have had a better time developing my phone application. Reading this over I realized that there is a lot that goes into the development process and simply writing the code isn’t enough. It’s like baking a cake, everyone can follow the instructions to bake one but if key details are left out then it might not taste good, software development is the same way. It’s important that the code is designed in a way so that it can last. In my next project, I want to focus on refactoring for the most part. Code quality is very important and being able to make quality code will save me time and prevent any struggle.

Link to “Simple & Effective Way to Write Object Oriented Code”:

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

My previous two attempts at getting my blog aggregated to the CS@Worcester blog have failed for one reason or another! (I assume). I must, however attempt posting once more and hope that through divine intervention, the aggregator decides to pick it up this time.

This situation reminds me of a quote by the famous pirate war-lord Vaas Montenegro: “The definition of insanity is doing the same thing over and over and expecting different results.”

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

We all have people we look up to, those who we see as guiding lights in the unpredictable lives we all live in. These special few, these mentors can be anyone, from friends, to family, to anyone in between. Having a mentor does wonders to the process of learning as well as providing a source of motivation and consultation when you find yourself struggling or at a dead end.

In ‘Apprenticeship Patterns’ by Hoover, Dave H., and Adewale Oshineye we see the pattern of seeking mentorship described in detail. Consider being an inexperienced software developer who has run into dead end after dead end while developing a new piece of software. Often we turn to those more experienced than us for insight into our problems and this case is no different. We seek out anyone who has had a similar issue and ask what they did in that situation.

Finding a master craftsman and learning from them is the goal of all aspiring apprentices and an ideal that we all seek. This however is often very rare today so many of us will find mentors who we can gather advice from regarding their own past experiences. Our field is relatively young and often changing, leaving few master craftsmen to teach those who are just starting out. Along with this many of these masters may not be physically available to you. This is where the mentors arrive to fill in the gaps.

Weather they are a coworker, a dear friend, or an anonymous individual online, a mentor can mean the difference for many software developers out there. They can offer insight on their prior experiences that may mirror your own, expose you to new ways of thinking, or just offer genuinely good advice. It is just another way to break your coding block when you find yourself stuck with a nonfunctional or misbehaving program you are attempting to get working.

With that said however, we all ‘walk the long road’ at the end of the day (Apprenticeship Patterns Ch 3). and finding someone to guide you can be hard so I will leave you with a recommended course of action by the authors. Find a library, or community with an active mailing list and being observing any messages left there. Over time you will pick up on the values of the community and which members are patient and willing to teach others. At the next opportunity, seek them out and establish that first connection with them in order to see if they would be interested in offering any informal advice or lessons they have learned over their time.

Bibliography:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

In the first Craftsmanship post I made, I mentioned that I am reading through Hoover and Oshineye’s book named “Apprenticeship Patterns”, which outlines certain patterns that inexperienced software developers may adopt so that they may overcome any potential hurdles during their personal learning experience rather than providing technical solutions. In fact, in that very post I mentioned (though not by name) two of such patterns, namely “Craft over Art” (introduced in chapter 3) and “Record What You Learn” (introduced in chapter 5). Though I may expand on these two particular patterns in a later post, I want to first address my reactions to one of the very first patterns that are introduced in the book, namely “Your First Language”.

            Briefly put, “Your First Language” is a pattern that is meant to address a software developer’s potential issues that may arise due to the fact that, though they may know multiple languages, they lack sufficient fluency in one of them. As such, such lack of fluency may put the developer in a difficult position when they are needed to work on a project that needs to be in a specific programming language. In this case, the book suggests picking a specific programming language to learn and master, preferably one that is used by any experts one might know. Now, it is important to specify that “learning a language” is not simply achieved by reading some resources related to a specific language, but by using that language to solve problems and actually apply what has been learned. Thus, by continuous application, a software developer may hone their problem-solving skills, which then may help them in learning other languages as well.

            While I personally found this pattern to be particularly helpful when I first started studying Software Development, I feel like my experience has changed the way I approach specifically learning a programming language. Though becoming fluent in a language is important, I believe it is also important to be proficient in the learning process itself. In my case, while I was learning my first language, I also made sure to internalize what that language was composed of in terms of concepts and structures I could use so that, when there is a need for me to switch to a different language, I would have some expectations as to what concepts I should expect to encounter and only worry about syntax while learning the new language.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

This week, I read a pattern called Breakable Toys. This pattern occurs when an apprentice needs an environment where the apprentice is allowed to fail and redo his projects as many times as possible. The main purpose of this environment is to make apprentices or software developers feel free to make mistakes and they can learn from failures until they succeed or until they have a deep understanding of a concept. To solve this problem, the author recommends to his readers a solution called Breakable Toys which can be broken many times; and the consequences of the failure will not affect anyone else, except the person playing with the breakable toys. The breakable toy here can be anything that an apprentice can use to practice techniques, try out new ideas, or to learn new things. Furthermore, breakable toys should be relevant and useful to your life, such as building a wiki, calendar, address book, or game. A breakable toy also should be fun to ensure that you enjoy playing with it and can stick with it long enough to learn everything you need and to enhance your essential skills.

For myself, this pattern is really interesting because it is similar to a method I have taken to learn a new concept or to practice a technique. However, after reading this pattern, I think I have used breakable toys to learn computer languages ​​in the past. To learn the Java language, I wrote some programs that are used to manage a coffee shop or a bakery. My programs would take input from the customer to place an order, then print a receipt, but at that time I didn’t know any tools to store those data into a system. Fortunately, I had the opportunity to learn about MySql, a tool that helps me store and manage data of a system. So, I tried to develop those programs to link them to the database in MySql. That way, I can play with the Java language and also gain a deeper understanding of how to use MySql tools. Furthermore, I have also applied the breakable toy method to learn python language. I wrote some of my own games in python with simple ideas after watching a few tutorial videos on YouTube. Although they are just simple games, it is a great environment for me to play with what I want to learn. On the other hand, I can also freely break the code at any time without worrying too much about the consequences. In conclusion, I believe that breakable toys is a good method for software developers to learn and to experience any tools from zero to hero.

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