Category Archives: CS-348

Addressing Technical Debt

Similar to my last blog, I wanted to focus on how to implement certain aspects of Scrum in an effective way. While exploring articles related to sprint planning, I came across a crucial aspect not covered in our class, technical debt. The article “How to Run an Effective Sprint Planning Meeting + Tips to Plan Technical Debt Work” by Cate Lawrence, provides strategies for making sprint planning less overwhelming while also highlighting the importance of preventative measures for technical debt. In this blog, I will focus on the technical debt portion of the article. Technical debt is a term used to describe future complications, that are time and resource intensive, that arise from expediting development instead of properly completing the product. It is the tradeoff between immediate gains versus long term consequences.

The article provides three steps for incorporating technical debt into sprint planning. The steps are:

  • Make technical debt visible

Recognizing potential issues and highlighting them for the team is important. Letting those issues accrue and not addressing them seemed like the opposite of the Scrum values. You should be adapting to unexpected issues or requests, not planning to have issues in the future.

  • Determine the business impact of each debt item

I could see how it may be enticing to take shortcuts during a Sprint. Convincing the team or management to not take these shortcuts and to tackle these issues will only help development, but it may be hard to do. Instead of focusing on all the technical issues in front of them, highlighting how the debt will come calling in the future felt like the appropriate response.

  •  Bring it to your sprint planning meeting

After visualizing the issues and showing why it would be best to deal with them now, including them in the next sprint plan is the final step.

Though not the main point of the article, it highlighted that technical debt was a neglected topic in sprint planning. I chose this article due to the steps, but also because it felt like something everyone should add to their Definition of Done. Even if everything “works” correctly with the code, knowing that there could be further problems due to the expedited nature of the sprint, the code should not be seen as done. It should not be ignored and should be addressed immediately or in the next sprint. Hopefully, these steps and the discussion on technical debt in the article will be helpful. In the future, I will try to address these types of issues using the steps, but also incorporate this into the team’s Definition of Done.

Link to the Article: https://stepsize.com/blog/how-to-run-an-effective-sprint-planning-meeting

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

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Code Etiquette Across Languages

    In the past weeks we learned about proper code etiquette when structuring your code. Most of our focus was on java methods and classes, and how to name and structure them so that other developers could better understand our code. Re-establishing the basics of clean code was an essential part of our studies in programming, but it got me thinking about other languages. How do the rules of clean code manifest in different coding languages, and what quirks do other languages have that force them to follow different rules? For the most part, when it comes to object-oriented programming the rules are consistent across languages and do not really need any modification. Keep It Simple Stupid and Don’t Repeat Yourself are principles that hold merit regardless of if you are using Java or C++. Keep code separated by whitespace and indented to create sections of code unified in their purpose, name variables and functions with their purpose clearly displayed, and keep each function’s purpose simple. All these rules and practices are practically universal and have helped to inform countless developers to create much more readable code. When it comes to languages outside this paradigm, however, the rules take a bit of a shift. 

     SQL is a database language with different rules regarding how it functions and thus has its own etiquette. For instance, CamelCase is discouraged in naming conventions due to its difficulty being scanned quickly. Abbreviations should be avoided; you want to be able to tell exactly what is in each table and column. A proper column name should look something like first_name orcustomer_id, using only lowercase, joined by an underscore. There are also common suffixes that are used in relational databases, such as _id, _name, and _size. These are due to certain columns being commonplace in databases, sometimes serving a specific purpose like id. Speaking of id, it is a common suffix because it is bad practice to only name a column ‘id’. Indentation and white spaces, on the other hand, are implemented quite similarly to object-oriented programming. Keep queries separated by white spaces, and indent JOIN statements to create readable sections of code. To be honest, in my database class I have not really been able to use any of these rules, and my code tends to be simple. Though I think in the future learning these other rules will serve me better and make me a better, more well-rounded developer. You can find all of the practices in the etiquette and style guides below.

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Linting For Non-Inclusive Language

Last week we went over linting for non-inclusive language. During class, I was confronted with the idea that certain phrasing that I often use could be taken negatively. My last blog was about the best practices for software documentation. The blog I found mentioned inclusive language briefly at the end and didn’t go into much detail. Because of this, I decided to find a blog that focuses on how to write inclusive documentation.

The blog I found that went through this topic is “How to write inclusive documentation?” by Selvaraaju Murugesan. In this article, Murugesan breaks down how to produce inclusive documentation in five steps: (1) Use gender-neutral terms, (2) Choose a neutral and friendly tone, (3) Avoid using slang words, (4) Use visuals that are diverse in nature, and (5) Use the right terms when discussing accessibility and disability. The directions and reasons behind each recommendation were clearly explained with examples to aid in understanding.

Because writers do not know anything about their audience there are many cautionary steps that a technical writer has to take.  In the new day and age, writers should keep in mind to write in a gender-neutral way to avoid discriminating against women and people of the LQBT+. He also advised using wording that removes cultural bias. He steers clear of terms like “slave-master architecture” as well. He also mentioned that local slang words may be offensive so it’s best to avoid using them. Terms that can be considered judgemental, patronizing, or exhibit euphemisms should be avoided as well. 

As alluded to in my previous blog, I have experience checking for non-inclusive language because I worked on code for Libre Food Pantry and Thea’s Pantry. When working on the linters for these projects, I discovered that there was a linter that checks for non-inclusive language. I didn’t give too much thought about the changes that the linter suggested. It wasn’t until recently in class that I gave it more thought. I didn’t think about why using “simply”, “clearly, or “of course” could be an issue for the audience. It is important to avoid deterring others from using software or wanting to be involved in the tech field. I realized that it is important to recognize that not everyone will find something simple to implement so to imply that it will be is not the best choice when trying to be inclusive. 

After going through the class activity and reading the blog, I have gained a better insight into how to choose my phrasing carefully. Although it may be slightly difficult to break certain habits, I am now better suited to identify non-inclusive language and will apply my knowledge to future projects.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.