The book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye covers multiple patterns important to being an apprentice. One of these patterns is called “Expose Your Ignorance” and centers around the issue of not knowing enough about a topic kind of important to the task at hand. Many people’s first instinct is to feign competence in order to avoid worrying their peers and suffer through embarrassment. The pattern instead suggests that people admit their shortcomings and ask questions. It might be hard to do but the benefits far outweigh the risks like learning important information sooner rather than later for example. Doing this has the added benefit of developing the learning ability through enforcing a “not knowing” mentality which just means to approach a situation if you were a novice. This mentality pushes an individual to broaden their horizons rather than becoming an expert on a single subject in a specific context. It also allows one to form strong relationships since this will be showing others your learning ability and flexibility.

I’ve had trouble “Exposing My Ignorance” for most of my life since again, most people’s first instinct is to feign competence. And of course, that wouldn’t work out since people would get mad at me for not knowing something and I’d end up barely learning anything. But I would still keep up this behavior until either late high school or early college mainly because there were some people in my life that would get mad at me for even asking questions. The reason why I broke out of that habit is because as I got older, I realized that there was so much I had no clue of doing. So, I started asking questions without caring what other people thought because I wanted to learn. For example, I wanted to learn to do my laundry so I just asked my mom to teach me and now I still do my own laundry. The same principle applies to software development; If you either don’t know something or aren’t confident in your knowledge on a subject, ask questions since there’s no real harm in doing so.

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

Concrete skills are something I feel as though I have an abundance, and simultaneously, a lack of. I guess this depends on what kind of skills are being referenced. If data structures, algorithms, or Leetcode is in question, I have some confidence. Not only are these topics I enjoy, but I also have solid knowledge in these areas. When it comes to automating tasks, or something more applicable to my current capstone situation, such as getting a strong grip on Docker and how each part of the project can be integrated with it, I feel… less qualified. 

The problem is, I think I can get to the technical knowledge I have, but only via the technical knowledge I am lacking. These barriers become apparent when working on a large project like the capstone. I look at the backend components, and I feel solid, even with little JavaScript experience. But picking up Vue.js makes me feel like I’m swimming in circles. There’s no point in making a backend without a frontend to support it, and I know this, but I’m not happy to confront it as it means abandoning my comfort zone for some crazy new frontend world.

          The learning pattern on concrete skills puts some much-needed pressure on me. It points out that I can have all the knowledge of theory and all the ability to learn quickly in the world, but if I can’t put real technical skills on a resume, I’ll never make it past the first round of hiring interviews. Rather than trying to find ways around the difficulties I face in everyday software development life, I should highlight my weaknesses and mark them down as learning opportunities.

          There has been a plethora of times in my CS career at which I confront a problem I have been avoiding and the knowledge I gain suddenly seems to apply everywhere. For example, last semester I learned the state design pattern, and because it came with some confusion, I dropped it quickly enough. Now, as I tried to make a Markov chain simulation in Java for my Math Modeling independent study, I realized a state pattern was a perfect fit. It took a couple hours, but I got it down and it feels great not only to have learned and used something new, but to know I have the knowledge to use whenever I need it going forward.

          I think my first focus should be some more surface level skills. As the chapter points out, the question, “If we hire you today, what can you do on Monday morning that will benefit us?” is one of the most important questions of the interview. If my best answer is, “Try really hard to get up to speed,” I’ll be job hunting for a long, long time. My new goal is to collect the skills I don’t know or feel uncomfortable with that are more common and focus my spare time on them. It will make daily life as a developer easier and take me further in my career faster.

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.

After completing my apprenticeship introduction blog post and two different patter reviews, I am excited to keep reviewing more. For the next pattern from the textbook that I have chosen to review, I chose the “concrete skills” pattern. The book describes a situation in which you are trying to work with a group or at a job in which you do not have a very strong background in yet. This is ofter one of the most inconvenient thing when looking for starter jobs. Most jobs want individuals who have a good background so they know you will be a good fit for the job. The book also supplies us with a great solution to this problem however. Basically, it states that you will have a better chance getting the job if you can prove that what you lack in background work, you make up for in your ability to learn quickly and work hard to learn new things on your free time as well. The more jobs and projects you can accomplish/work on, the better your portfolio and background becomes overtime. Eventually you will find it easier and easier to get where you want to get, and it all starts with your first several projects/jobs. This specific apprenticeship pattern resonated with me primarily because I personally do not have a great background yet and am trying to create a good one. The advice from this section was super powerful, and to be honest, this might be one of the most important concepts discussed in the entire textbook!

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.

https://techterms.com/definition/framework

            The link above leads to a website article that explains what a software framework is while giving some examples. The two main reasons I chose to write about this topic is because of one, it’s listed as one of the topics to be covered in class and two, I’m not too familiar with the definition of a software framework. According to the article, a software framework is essentially a set of tools that act as a foundation for software developers. These may include preset classes, APIs, compilers, code libraries, and predefined functions among other things. Examples of software frameworks include Microsoft’s .NET framework, Android Application Framework for Android, Cocoa Touch for iOS, and Cocoa for Mac OS X.

            From the definition given, the practicality of a software framework seems pretty apparent to me. Rather than creating classes and functions from scratch that will most likely see reuse, set them together in a ready to use package in order to save time and effort. It’s similar to how someone would buy ingredients at the supermarket rather than making each one from scratch. I’d imagine that software frameworks also have the added benefit of increasing portability for software that uses a specific framework. Take for example my computer which has .NET framework on it. If I were to create a piece of software using .NET, then another machine which has a similar version of same framework would be able to run my software with no additional setup needed. To be fair this is only speculation on my part; I haven’t checked whether or not this is true yet. But then again, I remember having to install a newer version of .NET framework in order for my computer to run software correctly so I might be on the right line of thinking.

In the case of porting software to machines with different operating systems, I’m not sure what role frameworks would take. I am pretty confident that software frameworks aren’t limited by operating systems. One example being Java Collections Framework or JCF for short which, as far as I know, isn’t limited to an operating system like .NET is. When a difference of frameworks is a factor, I assume that a software developer would have to make up for a lack of a framework’s components in a machine in some way. And that’s on top of the usual changes needed for porting software between operating systems.

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

As I was reading some articles, websites for my previous assignments, I came across the term refactoring a lot. However, that was not the only time seeing that as it is part of the course syllabus. I decided to learn more about refactoring and write something on it for my weekly blog post. After going through some resources, articles I finally settled on this blog post that talks about refactoring. The structure of this blog is made simple, easy to learn and understand especially for beginners and those new to the term. It also provides links to some terms, books and some other IDEs mentioned.

This blog defines refactoring as the process that involves editing and cleaning up previously written software codes without changing the function of the code at all. Blog talks about the importance of refactoring, reasons for refactoring and how to perform refactoring. It also provides some techniques on how to perform refactoring. Each technique is well explained and broken down into subtopics and/or steps with some diagrams provided. Also, blog talks about when refactoring is not needed, best practices for refactoring and general summary refactoring.

In this blog I learned that the basic purpose of refactoring is to make codes efficient and maintainable, reduce technical cost, improves readability, and help prevent future bugs. A term that I found interesting as I was reading about the importance of code refactoring is code rot. Further research from Wikipedia explained it as a software decay that is a slow deterioration of software quality over time leading to software becoming unusable or in need of upgrade. Refactoring is important as it help to avoid this code rot.

I also learn that the best time to refactor is before any update or additions to an existing code. This is so as it improves the quality of code and should be done in small steps as possible. Other practices include planning refactoring project and timeline carefully, testing frequently and involving Quality Assurance teams and striving to focus on progress.

I thought that refactoring is always needed especially dealing with very high coded software programs and systems, but I learned from this blog that refactoring is not needed when an application needs to be completely improved.

Some techniques of refactoring I learned are Red-Green Refactor, Refactoring by Abstraction, Composing and Simplifying methods. Before applying the Red-Green Refactor technique, there should first be consideration of what needs to be developed. These developments need to pass basic testing before improvements can be implemented. Refactoring by abstraction is used when there is a large amount of refactoring to be done. I learned that extraction, one of the processes in Composing method, involves breaking down of codes into smaller pieces to find and extract fragmentation. This code is then removed to a separate method and replaced by a call to a new method. This process also involves classes, interface and local variables.

I hope others find this blog useful as well.

https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/

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

Similar to how code and design smells were covered in class. I was interested in digging more into code smells and seeing how they influence development of code and how they can be rectified. I found that this would be a useful topic to further delve into because being able to pick up smells from your code will help prevent further mess in the future. To supplement my learning in this topic I got around to watching a seminar or conference video on code smells in java, which was hosted by Stanly Lau, a software development coach/mentor and also someone having experience of looking at companies code and giving advice on code smells and refactoring. In his seminar he basically went over code smells and refactoring techniques used to remove to code smells; in the seminar this is done by an example he goes over with the participants.

Besides going over code smells, what I really like from this seminar, was how he explains the significance of catching code smells in our code; he explains this via system diagrams to show that code smells are in a reinforcing loop relationship with bad code, and bad code is in a balancing loop with developer motivation; because of this we need to reduce bad code via refactoring. Refactoring is important because it instigates flexibility and helps to remove bad code or code smells. And flexibility is important in order to deal with change and he states “[i]f you cannot deal with change or how to improve with change easily, then you are probably in the wrong business”. The was a powerful I really appreciated, that change is inevitable in programming and in order to deal with change we must make our code more flexible, and that is where finding code smells and refactoring comes in.

I also enjoyed watching Stanly going over his example code of detecting and refactoring the code smells. His methodology appeared that he would look at the code and try to understand what is going on with the code (reading before coding) and then would see if he can detect any code smells such as comments, duplicated code, feature envy, long methods, primitive obsession, or magic number. Afterwards he would choose a means to refactor that code smell; the aspect of refactoring that he describes as ‘making small steps without breaking the code for too long’ is what I found helpful and will incorporate next time I am reviewing my code. Rather than just choosing a technique such as extraction method, I should be compartmentalizing steps to fix a problem and then work on improving on that refactoring. Overall it was a supplement for my learning in code smells as I was able to see a demonstration and also learn some more techniques use ide’s as well.

I attached the links to video as well as the diagram that explains effects of code smells in a developers environment below.

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

For this week I’ll be covering the pattern, Breakable Toys, from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The breakable toys pattern uses small personal projects to teach new techniques. When in a professional environment, playing and learning with the project is not an option. To keep ourselves learning new skills after college, the best thing to do is to create personal projects that allow us to make mistakes and grow as developers. These projects, or breakable toys, are chosen by us and will likely hold more interest than work projects. By working on these projects, we can learn the workings of a project without the fear of consequences of our mistakes.

This pattern is a bit obvious, but I still think it is worth reminding ourselves of. I sometimes find myself tired of working on a needed project and begin to lose some enthusiasm. A breakable toy is always a fun and educational way to lift my spirits while still progressing my skills. To me, breakable toys are more than just a consequence free environment to develop in, breakable toys renew my enthusiasm in the craft.

When I just started learning programming back in ’08, I felt like a whole new world had opened up. There was so much to see and learn, and I was psyched for what I was to learn. My first breakable toy was a text-based game. It was terrible, messy, and bugged but I learned a great deal in the process and because the project was personal, I could do whatever I pleased without concern. While I have not worked with that project in over a decade, I can still remember some of the lessons I first learned while making that game.

I would highly recommend exercising this apprenticeship pattern. This pattern combines the developer’s interests with a stress-free environment to create a project that is exciting and rewarding. I think of our coding skills like cooking, part science and part art. To grow as a programmer, it is important to remember that we need to push our boundaries and experiment is we are to learn. A breakable toy is the perfect project to practice old skills and develop new ones.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.