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.

 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.

 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.

For this blog entry I decided to choose something related to Agile. In the blogpost, Agile Principles: The Complete Guide To All 12 Principles For 2025 written by Sean O’Connor, he goes over how Agile’s flexibility gives it real world benefits for businesses, development teams, and customers. Much like how with what we went over in class, Sean O’Connor explains that Agile’s strengths aren’t so much about speed of delivery of a product, but in it’s efficiency in producing a working project, with speed as positive byproduct. As someone who’s never been good at long term planning, what was explained in the blogpost really resonated with me. Things like catching problems early when it hasn’t become a core “feature” of the software, building what the customer actually needs rather then wasting time, and especially the part of creating quick wins, are some things that I value in a game plan. The blogpost then goes into 12 principles that makeup all Agile methodologies, a couple of which really stood out to me.

One of the principles was delivering working software frequently. I like the idea of real progress you can actually see and use, not just what it could potentially be. It’s nice when you get to see something that actually works early, even if it’s just a rough version. This approach makes more sense to me than spending weeks or months planning something that might not even be what was wanted, which is just a huge waste of time and energy. So to me being able to get instant feedback, learn faster, and fix problems before they turn into something major, is huge.

Another principle that ties into that is measuring progress by working software. That line really sums up Agile’s idea of “cutting out the chaff”. It’s easy to get caught up in planning, documentation, or presentations that sound good but don’t actually move the project forward. A working prototype says more than any report could. I think that same logic applies to class projects too, seeing your code actually run feels like a real measure of progress, not how well it’s outlined on paper.

The principle of simplicity, or “maximizing the amount of work not done,” also hit home for me. It’s about focusing on what truly matters and using just enough time and energy needed. I tend to overthink projects at the start, but this mindset reminds me that getting the essentials working is more productive than building unnecessary features. Fewer moving parts also means fewer ways for things to break (something I know all to well).

All in all, it’s reassuring to see that my “slacker mindset” can be the basis for something actually productive.

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