I recently read the blog post titled “Why Code Reviews Are My Highest-Priority Work” by Jordan Edmunds. In the article, Edmunds explains why he regards code reviews as the top priority work. He outlines several reasons. First, that doing reviews early reduces the team’s merge conflicts and speeds up cycle time. He also notes that if a review happens soon after the author writes code, the author still has fresh context, making fixes and tests easier. He points out that timely reviews improve overall team productivity, and supports shared responsibility. He discusses common objections and shares how he integrates reviews into his day.

This blog post directly relates to our course topic of Code Review. I chose it because rather than just defining what code review is, Edmunds gives practical ideas into why it matters, based on real experience in a programming context. Since our course material covers this topic, this article provides a good example of how Edmunds’s code review ideas is applied. I felt it would help me connect theory with real practice.

Reading the article made me realize that code reviews aren’t just an after the thought thing to checkbox but a good practice for improving code quality. I learned that timing matters, a review done soon after code submission is far more effective than one delayed. I also like the emphasis on context, for the programmer, having fresh understanding of their changes makes review feedback much easier. These ideas provided by Edmunds helps shape how I think about code reviews now. I’ll aim to review often and hopefully the fresh context will help me pinpoint any and all problems present.

Personally, this article made me reflect on my own habits where I often skip reviews or wind up doing them late, when I encounter a problem running my programs. I’m now aware that this can slow feedback and especially development. After reading this blog, in any coding assignment or personal project, I plan to start reviewing written code quickly. Reviews are an important process which we upkeep standards, share progress, and improve code maintainability.

In summary, this resource has helped me understand the value of code review, and given me good ideas for applying it in team and personal works. By participating actively and thoughtfully in code review, I’ll hopefully write better code and contribute to smoother team processes.

https://medium.com/%40jordan.l.edmunds/why-code-reviews-are-my-highest-priority-work-8e9b4c410887

From the blog CS@Worcester – Coding with Tai by Tai Nguyen and used with permission of the author. All other rights reserved by the author.

For this post I listened to the Sourcetoad podcast called, Leveraging Frameworks for Your Software Development Project. This podcast features three software developers who work for Sourcetoad, a software consulting and development firm, by which they discuss software frameworks. https://www.youtube.com/watch?v=ik4d2Jf7Rik&t=1539s

To begin with frameworks we must define what exactly is a framework. A framework is collections of pre-built code that builds the blueprint of the app; furthermore, without need to write the code yourself. Frameworks are tremendously useful because with any coding application, you are trying to help solve a problem. To initiate any project, there are these kinds of “price of entry” such as login, authentication, security, database, and server to name a few. With these examples, the framework gives you these things right off the bat, pre-built modules, which allows you to start faster on the solution.

Now the best part about frameworks is that the vast majority are free. Free being that the code is open source; software made by the software community for the software community. Anyone can view, edit, and modify the software. 

Now what would be an instance you would not want to utilize a framework. Say for instance you have a simple application that utilizes a framework, but while you run the code you notice it is rendering slower than expected. This is because with any kind of framework you are getting a lot of pre-built code, which you might not utilize which will slow down the rendering time. Wonderfully put in the podcast, “the great thing about a framework you get a lot of stuff, but you also get a lot of stuff.”  

With frameworks you can build on top of them and one popular method of doing this is by using a CMS: Content Management System (frontend and backend). A CMS enables users to manage the content on a website themselves, without needing to know how to code; gives non technical people the ability to make changes on the website instantly. A con of this is that it is vendor locked in, meaning it cannot transition easily. 

There is also a headless CMS. This is responsible for editing and storing of the content, but is not responsible for how the content is presented visually; it has no frontend, only backend. Some pros of a headless CMS is that it’s an easier content manager, gives developers more freedom to develop code at scale and also, content can be created once and published everywhere.

Overall, I’ve heard the word “framework” get tossed around in the computer science world, but never truly did have a grasp on what it really was. From listening to this podcast, I feel great about what it is and eager to start a project using a framework and even more so exploring the world of CMS and headless CMS, once I feel comfortable with frameworks.

From the blog CS@Worcester – Programming with Santiago by Santiago Donadio and used with permission of the author. All other rights reserved by the author.

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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