Category Archives: Week-2

Week 2 – Your First Language

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.

Retreat Into Competence

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.

Code, Test, Refactor!

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”:

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.

Third time’s the charm… (or not?)

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.”