Category Archives: Week-15

Code Review Essentials: A Critical Tool for Development

Blog Entry:

As a student deeply involved in computer science, understanding the significance and methodologies of code review is pivotal. This week, I chose to delve into an article from freeCodeCamp, titled “Code Review: The Ultimate Guide,” which explores the intricacies of code reviews in software development. This resource is particularly relevant to our ongoing discussions in class about software quality and maintenance.

Summary of the Article:

The article comprehensively outlines what code review entails and why it is a critical practice in software development. It discusses the benefits, such as catching bugs early, improving code quality, and fostering team knowledge sharing. Moreover, it provides practical tips on how to conduct effective code reviews, emphasizing the importance of a constructive attitude and specific, actionable feedback.

Reason for Selection:

I selected this resource because, as we learn to code and develop software, understanding the peer review process is essential for professional growth and skill enhancement. This article not only complements our coursework but also offers practical advice that can be immediately applied in any coding environment.

Personal Reflection:

Reading about the detailed processes and benefits of code reviews has been enlightening. I learned that effective code reviewing goes beyond merely finding errors; it is about collaboration, learning, and improving as a team. This has changed my perspective on coding assignments and projects. Instead of viewing them as solitary tasks, I now see them as part of a broader, collaborative process.

I am particularly struck by the emphasis on the mindset and communication skills needed during code reviews. The idea that feedback should be constructive and focused on the code rather than the coder is something I plan to carry forward into my professional life. This approach not only minimizes potential conflicts but also enhances the learning environment, making it more open and conducive to improvement.

Application in Future Practice:

Going forward, I expect to apply the principles from this article in my class projects and eventually in my professional work. Understanding the dynamics of effective communication and feedback within code reviews will be crucial as I work with others on software development projects. This will help in creating more robust, error-free software and in building a supportive team environment.

It is an important skill for everyone regardless of their place in the chain of development. The principles also apply outside of the field of computer science as a successful review is a part of any team process.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

REST API (Token blog)

When I was first introduced to the concept of an API, a shortened abbreviation of Application Programming Interface, I never thought of it being used far outside the scope of Computer Science.  However, as I revisited some software that I used in the past and observed the current software I worked with recently, I was more than surprised by the fact that an API is universally used across the Internet.  For this blog, I explored a blog called “10 Most Popular Frameworks For Building RESTful APIs” written by Developer Advocate at Moesif, Preet Kaur. In this blog, the author explained that when deciding on the API framework to use, you needed to choose one that uses a programming language that you are familiar with, but you can also use in spite of its shortcomings.  Further down the blog, she gave some examples of popular API frameworks that are used by many developers; one of those frameworks that was mentioned was Express JS, a framework I am familiar with.

One of the biggest contributing factors that brought me to use this article for this blog is not only the different frameworks that Kaur had given examples of, but also where you can find and learn about them.  Reading this blog got me hooked on the many different types of API frameworks that I could look at to familiarize myself with each that may give me a better understanding of the specifics of REST API for my drive toward a career in Software Engineering.  Even if the frameworks in question were written in programming languages that I am not as efficient in programming in, I still believe that this blog has helped me in understanding the overall meaning of building an API for use in creating applications and beyond.

My biggest takeaway from this blog is that the API framework you use to build an application, software or other kind of design is not only dependent on your skill at programming or engineering, but also what your goal is with using the framework you choose for your creation.  While this blog was more general than the previous ones I read through, I still stand with a vision that the API framework that I use will only be as helpful as the skills I use to develop and engineer my path to a greater goal in creating the perfect software.

Reference: https://www.moesif.com/blog/api-product-management/api-analytics/10-Most-Popular-Frameworks-For-Building-RESTful-APIs/

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

“Record What You Learn”

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

“Share What You Learn”

It is essential to know when to fail. So, we start learning when we fail. In our journey, we experience these expansion failures. This template explains how to speed up the sharing of the knowledge we have gathered and pass it on to people. 

When I read this pattern, we were working as a team, and we agreed. Communication is the key. Communicating our knowledge can make a difference. Always be supportive and help each other. As a team, they are responsible for all tasks. Why are you selfish about what you know? After all, it won’t help anyone, and it won’t help you either. The problem is that you must rely upon others to catch up. And another point is that they may not like or appreciate if you are a trainee and if you can influence your team or individual based on your experience, so knowing I can’t do that. Therefore, the model shows that you or someone else can try to save what you have learned along the way only if you need it for future purposes.

For this pattern, I disagree on the part on whether it may not be appreciated towards others. But the problem is that I do not know why it would be a problem as people can be mature enough to give feedback on the person taking their time to share what may be a discovery for others. They can always have the option to not accept the knowledge and do, however. Should not be hindered from one or more person opinion. 

Believe that it is important to share the knowledge acquired. knowledge is power. Also, teaching this knowledge is a great and powerful collaborative tool that we must learn ourselves. I know as a software developer; I will face these challenges and must make the right choices for the best of the team I work with or for myself to perfect my work ethic. People may not like what others have to say and may not do it the way you expected. But pay more attention to this cause. I practice recording everything I learn and realize that delivery is important, or I can quickly contact someone in a situation like this.

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Find Mentors

Summary:

Find Mentors pattern is about asking for help while exploring the unknown. Every time we decide to take a new path – learn a new language, we do not know what is in store for us and therefore have no clue as to how deal with problems that we might face. The pattern recognizes that as new apprentice we will need help facing these problems and in reaching our goal.

The solution pattern provides is to learn under a master craftsman in the field of your choosing – a mentor. The pattern also realizes that as a novice it is difficult to identify a true master craftsman and therefore during the process of acquiring the new skill we will be guided by a number of mentors with diverse levels of mastery. The pattern states that it might be easy to find authors, bloggers, professional speakers, and developers in computer science field. However, there are two problems; first, they might not be interested in mentoring; Second, asking someone to be your mentor can be very intimidating. The important point pattern makes here is to have determination and remember that the risk of rejection is very low compared to huge opportunities having a mentor can provide.

The pattern also warns us about blindly following someone. We need to keep our eyes open to the mentor’s weakness and resist the temptation to believe everything they say. No one knows everything about everything. Therefore, we need to keep finding other master craftsman and keep polishing our skills.

Why I choose this?

Computer science is a very difficult field to begin with and then on top of it – it is an ever-evolving field. The amount of knowledge available is immeasurable. The pattern ‘Reading List’ helps us organize the books we need to read, which as we all know does not give practical explanation, real world connections or real time feedback. Moreover, to start our reading list and even to make sure that we are reading the correct books – we need to find someone we can trust – someone like a mentor.

Over the last four years I have been able to find a number of mentors. They have ranged from professors to my peers, family and friends to people in slack and discord communities. It has been an amazing experience. I have learned from them and with them.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

Summary:

Those who don’t learn from their past mistakes, are doomed to repeat it. ‘Learn how you fail’ pattern states that failure is an inevitable part of any learning process. And if we have not experienced failure than we are either not pushing ourselves to our limit or we are making a grave mistake of ignoring our faults. The pattern provides a very clear and concise solution, self- assessment. We need to identify and be self-aware of patterns, conditions, habits, and various behaviors that resulted in failure. The pattern also points that once we are conscious of our faults, we are given an opportunity to fix them. It’s like the saying,’ the first step to any solution is recognizing that there is a problem.’ The pattern also lets us know that accurate self-assessment can help us define our limitations. Pattern lets us know that its okay to not excel at everything and accepting these limitations forces us to rid ourselves of all the distractions and reprioritize our goals.

Why I chose this pattern?

To quote Thomas Edison one more time, “I have not failed, I’ve just found 10,000 ways that won’t work.” This is a very powerful quote because if we don’t remember which road is incorrect, we might very well end up drowning.

‘Learn how you fail’ fits in perfectly after ‘breakable toys’, ‘Practice, Practice, Practice…’ and ‘Record what you learn’. “Armed with that self-knowledge…you allow yourself the choice between working to fix these problems or cutting your losses.” This is a very powerful sentence from the pattern. I have always been very self-aware of my limitations and therefore had my courses for the four years of my college well planned. Unfortunately, due to a fractured foot and a death in the family, I was operating at a bare minimum of my normal capacity. After a long and hard self-evaluating process, I concluded that I will not be able to finish both my capstone courses and even if I do, I will only be doing my bare minimum to pass the course and not for the learning experience. At this point, I decided to cut my losses- drop one of the capstone and do my best in the other one.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Nurture Your Passion

I decided to write on the importance of “Nurturing your passion” because as a senior who finished college and is going for the professional career, I think this pattern is a piece of advice. Being a great software developer isn’t something that happens over time. In contrary, it is time consuming, energy consuming and requires determination and sacrifice.

To become software developer, we will need to have a passion for software craftsmanship. Unfortunately, our daily activities often work to diminish this passion. We might be faced with demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues. It’s hard for our passion to grow when exposed to such hostile conditions, but there are some basic actions we can take to sustain it. Work on what we like. Find something at work that interests us, identify it as something we enjoy, and pour ourselves into it.

I have always said that loving what we do is what keeps us going forward and wanting to master I that specific domain of our professional life. When we don’t love what we do, we don’t even other putting the effort to master it or accomplish something great because our mind isn’t even there. Immersing ourselves I some of the great literature of our field can carry us through the rough spots when our passion is in jeopardy.

I think the best advice here is that if, as software developers, we find ourselves in a company that stifles or suffocates our passion, we need to have the guts to move on and go to for something that we love. This piece of advice is very relevant and important. I think finding a job that a software developer can at least partially nurture his passion is very important. We spend so much of our lives at work. So, it is very important to find happiness there, if possible. And when we don’t find it, have the courage and the positivity to keep looking until we find it because when we don’t love what we do, it affects our wat of working and also our mental health.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Stay in The Trenches

This week I have decided to write about Stay in the trenches. This refers to deciding to program even when the craftsmen receives a an offer that would pull him away from programming. Dave mentions that the minute the craftsmen stops programming, his skills will fade.

This has certainly been the case for me. In school there were semesters that brought me away from coding. There are many classes that are non programming and when I take so many of those non coding types of courses plus working part time, it was at times hard to find the time to code. So I could only imagine what would happen if I had a job where I couldn’t code every day. Especially with family obligations. I know that my uncle and folks that I have talked to in interviews mention that they don’t code anymore and that they miss it. So I completely agree that skills atrophy when the craftsmen does not use them.

Dave recommends finding alternatives to the managerial promotion. The craftsmen needs to figure this alternative out on his own and write down these rewards. This is something that I will figure out on my own as I have more work experience. I know that these days there are lots of oppurtunities for senior software engineers so I think that if I want to stay in a coding role I am confident that I this type of oppurtunity will exist.

This specific decision is a ways a way for me. But there are similar cross roads in the earler stages of my career. There are positions for new grads that involve different levels of coding. There are Quality Assurance roles that are part of the Software Development Life Cycle but it is not a role that is strictly coding. So it just goes to show that the apprentice will need to choose programming again and again. There are many roles in software that do not involve coding, and it is important to choose programming again and again. This is an important lesson that I will take into my career as I graduate and move into my career in software development.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Retreat Into Competence

It happens to everyone to feel overwhelmed, confused, and realizing how little we actually know or that we’re working on a project that is actually not going well. Retreating into our competence and regain it is he solution to this problem. Sometimes, stepping on the side is a good thing because when we pull back, then it’s easier for us to launch ourselves.

In the pattern, the author Dave H. Hoover says: “An apprenticeship is a roller-coaster ride. You will experience the thrill of learning new technologies, leveraging your knowledge and creativity to deliver value to your customers. But you will also experience the heart-in-your-throat terror of perceiving just how little you know compared to the craftsmen and experts you meet along the way. It can be overwhelming, particularly when a deadline is looming or when you’re dealing with production issues.”. Wen reading this, we can understand that this is a normal and inevitable phenomenon along The Long Road. Overcoming the fear of your own incompetence is the bridge between Expose Your Ignorance and Confront Your Ignorance.

This pattern is most relevant for people who have stretched themselves far beyond their ability. If your apprenticeship has you taking reasonable-sized steps forward, taking on gradually increasing responsibilities and technical complexity, then you may not need to take shelter in this pattern. But if you are really struggling or are barely keeping your head above water in The Deep End, look for opportunities to temporarily retreat. Sometimes you need to take one step back in order to take two steps forward. From this pattern, I just understand that pressuring ourselves and feeling overwhelmed, or a project not working and feeling frustrated, stepping off and pulling back will help us go even far. I love the way the author explained and said that when we pull back, then launch forward, it is like a some from a catapult. I am pretty sure we have all seen catapult and the further back we pull, the further the stone will go forward. Same with software, when we feel like we can’t do it anymore, let’s pull back and retreat into our competence. That will be the way we will regain it.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

The Deep End

This is one of my favorite patterns which is “The Deep End” because it talks about the importance of leaving our comfort zone and jump into the dep end. I love how this pattern explains the importance of being open minded and ready to confront anything because nothing guarantees that we will always be in a domain that matches our skill level.

Waiting until you’re ready can become a recipe for never doing a thing. Growth only happens by taking on the scary jobs and doing things that stretch you. There are opportunities that we will or may end up having, but they might be out of our comfort zone. Risks are opportunities seen through the half-shut eyes of fear. Meaning that taking that promotion or foreign assignment when it’s offered, even if the very real possibility of failure is staring you in the face. Being prepared to fail and recovering from that failure opens doors that the timid will never see.

Even though we advocate seeking out the most challenging tasks we are capable of, we still need to remember that if the water level is above our head, it means we’re drowning. Even in Enrique’s example, where he was changing his life in a big way, he was still moving to a country where he knew at least one person and could speak the national language. It is our responsibility to offset the risks of this approach by Finding Mentors and Kindred Spirits who can provide help when we need it.

It’s also your responsibility to Create Feedback Loops, so that if the challenging project starts to spin out of control you can catch it and get help immediately. Applying this pattern should feel brave rather than reckless. Willing to go and confront the difficulties and being ready to swim until we finally find the way out.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.