This week’s blog post I decided to research more about linting for non-inclusive language. The medium I selected is a blog post by Michael Bachand, an engineer at Airbnb. “Building an Inclusive Codebase” dives into the techniques engineers at Airbnb are taking to make their work environment more inclusive for everyone. In order to create a more inclusive platform, the development team must also be inclusive. To start, the team has increased the diversity in their teams to accommodate every demographic. Bachand emphasizes that building a diverse team will help empower both Airbnb’s hosts and guests. Inclusivity goes beyond forming a diverse team however.

The team at Airbnb discovered an issue with non-inclusive language in their codebase. After working with employees affected by these terms, the team presented a proposal to the Chief Technology Officer of Airbnb and got the approval to refactor the code to be more inclusive. Michael Bachand stresses that “acknowledgement and resourcing from the highest levels of management legitimized this effort”. The support from management and the CTO prioritizing the task produced a healthier working culture across all teams.

Airbnb’s development team broke down this problem into two key parts: preventing the use of this language and eliminating the existing language. One essential tool that was utilized was the woke linter which checked each pole request for non-inclusive terminology and suggested alternative terms to promote belonging. The team now had a proper tool to use, however, they didn’t send the tool to every developer immediately. The team took a unique approach by slowly distributing the tool to expert developers. These developers decided which directories the linter should access and which should be excluded.

Before our in-class activity on this topic, I never thought about how my sentences might unintentionally offend or upset someone. This topic has opened my eyes to how crucial having a linter tool is. Many of these non-inclusive terms sound offensive without the right context which is why every developer should utilize a linter of sort. Reflecting on the problem addressed by Airbnb, having the support from the CTO is reassuring to know that your work is valued by the company. I believe all companies should strive to create a sense of belonging in their work environment, no matter how big or small. I can confidently say that the information I learned today will stick with me for the rest of my career.

Blog Post: https://medium.com/airbnb-engineering/building-an-inclusive-codebase-bbaa2315e5b8

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

Not too long ago, I learned about the “Agile” methodology for the first time. I learned all about how following “Agile” allows for code that is always functional and that can be built off of in a much more proactive way than that of code produced through the waterfall approach. What I did not learn as much about, however, is the impact that following an agile methodology has on the customers, the vendors, and the project manners, as many of the lessons I took part in were developer-focused.  

In order to learn more about the impact of the Agile methodology project members, other than developers, I did some research and came across a blog post titled: “8 Benefits of the Agile Methodology” by Erin Aldridge. This blog post takes the approach of describing the benefits of using an agile process through the perspectives of people who would otherwise not be working directly with the code. 

CUSTOMER BENEFITS:

The article identifies the way in which incremental delivery of a project often results in higher levels of customer satisfaction, as well as provides greater customer involvement and input on what they are looking to receive as a final product. This higher level of customer satisfaction is also paired with a higher return on investment for the customer.

VENDOR BENEFITS:

From the perspective of a vendor, it becomes much easier to ensure a high-quality product, or a product that satisfies the customer when a new increment of the product is available at the end of each sprint. Increased level of transparency on the progress being made on any given project also allows for a vendor to more effectively work with a small-sized team and communicate in meaningful ways with the customer. 

PROJECT MANAGER:

While working with “Agile”, developers are able to get right to working on a project, cutting out much of the uncertainty that may be created as a project manager attempts to figure out all the parameters for the project. Project managers are also able to better select tasks to be prioritized first, and will find it much easier to keep track of project progress through the points emphasized during each daily scrum meeting. 

From what I have discovered, using “Agile” seems to be better for every member of the development process compared to other methods like the “Waterfall” process. I have also learned through this research that implementation of the agile methodology is more simple than often thought and improves nearly every aspect of the work process (as mentioned through points above). To add to this, I also now have a better understanding of the role everyone plays as described by someone who actively uses “Agile” in a real workspace. In fact, I now believe that the agile process is easy enough to implement that I will very likely recommend its use in future projects that I take part in. 

Blog Referenced: 8 Benefits of the Agile Methodology – Project Management Academy Resources

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

In many of the previous classes that I have taken throughout my college process, I have been tasked with writing code. However, in nearly all of the assignments I have received so far, instructions only require the code to be working or at most want there to be comments to go along with said code. After reflecting on this fact, I began to think more about how there must be some sort of standards for writing code; some sort of quality control when it came to preparing code for use in a professional environment. This is where the practices of writing “clean code” come in.

Recently, I have read a blog post called: “Writing clean code: best practices and tips for developers” by René Cadenas, in which the author went on to outline several key points to follow when improving the readability and cleanliness of code. I chose to read this article in order to develop a better understanding of the topic covered in class, as well as to create a better understanding of how I can implement the use of clean code practices in future workspaces.  “Clean code” is defined here as “code that is not only functional but also easy to read, understand, and maintain”. The author also wrote about why clean code matters, claiming that it leads to improved collaboration between developers, and that implementing defining features of clean code, like meaningful naming conventions, proper documentation, and reusable code blocks that don’t require other developers to repeat efforts and redundancy, will all lead to a final product that follows the principles of writing “clean code”. Other topics of emphasis in the blog post were: consistency of code, clarity of comments, and efficiency of the code written.

After having read this blog, and through our classes in which we had our own lessons of writing clean code, I now understand why it is such an important aspect of writing code. After reading the article, I learned about how much of a difference refactoring code can actually make when it comes to the readability of code, which I didn’t consider throughout our in class discussions. After seeing examples of refactored code alongside the same code in its non-refactored form, it really convinced me to try harder to implement these practices in my own writing of code. Moving forward from this point, I want to put a lot more thought into how I write my code and whether other people are clearly able to understand it in the same way that I view it. After all that I’ve seen on the topic, I think the best way to go about this is through practicing more on implementing these “clean code” practices in my own work. I think it might even be a good idea to use a separate “clean code” guide to double check code I write in the future before submitting it. 

Blog Referenced: https://blog.elaniin.com/writing-clean-code-tips-for-developers/ 

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

Tommorow, Not Today

As with many classes, topics, and projects I have been a part of for the last few years, I see a consistent pattern. The unwavering focus on what’s going on in the present and never connecting the dots on how something might benefit me in the future.

Code documentation is just one of the many examples I could come up with to further my point. Up until now, all my work has followed the motto of “me, myself, and I,” failing to see that in the future that won’t be the case. Eventually, everyone will find themselves a part of a team, and there is nothing worse than an amateur teammate. Let’s take a deeper look into code documentation and why it will eventually be an asset to not just you but also your future teammates.

Type of Code Documentation

Internal Code Documentation: Intended for developers inside the organization.

• Process Documentation: Provides high-level information like product requirements, roadmaps, notes, and reports.
• Developer Documentation: Provides detailed instructions for developers and staff for building, testing, deploying, or maintaining the software.

External Code Documentation: Intended for developers outside the organization who integrate with the product or need to understand its code.

• External Developer Documentation: Provides essential instructions for using source code, integrating with a product, and leveraging developer interfaces like APIs and CLIs.
• Enterprise Documentation: Furnishes information for IT staff involved in software deployment, covering hardware requirements, sizing, operational needs, and maintenance guidelines.
• Usage Documentation: Guides non-developer users on product utilization without relying on programmatic interfaces. Describes main functionalities within the product’s UI.
• Just-in-Time Documentation: Supports developers as needed, often in the form of knowledge base articles, FAQ pages, or blog posts, added in response to new features or requirements.

Low-Level or Inline Documentation: Resides within the source code and explains details of specific code parts in isolation, such as the purpose of certain functions and arguments.

High-Level Documentation: Describes the architecture, design principles, implementation guidelines, or other broader concerns.

Walkthrough Documentation: Describes flows, patterns, and other important parts of the codebase, especially for developers who need to contribute to the code.

Food for Thought

Documentation might seem straightforward, but there are some issues that must be considered whenever starting a new document.

• Knowing Your Audience: Depending on why/who you are writing your documentation for, you must consider their level of understanding when it comes to your subject.
• Updating Documentation: It is very easy to push changes to your software and forget to also push changes to documentation. This starts a cycle with co-workers where the documentation falls behind and becomes uncomprehensible.

Tommorow

Embracing comprehensive code documentation is not just a practice for today but an investment in our collective future. As we transition from individual contributors to collaborative team members, the value of clear, well-maintained documentation becomes vital to future projects.

Source – https://swimm.io/learn/code-documentation/code-documentation-benefits-challenges-and-tips-for-success

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

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.

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.

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.