Category Archives: Week 13

api uses

Starting the Docker service also starts the Docker Daemon. However, if you receive the “Cannot connect to the Docker daemon” error, the daemon may have failed to initiate.

Use the following command to run the daemon manually:

From the blog CS@Worcester – Andres Ovalles by ergonutt and used with permission of the author. All other rights reserved by the author.

Anti-Patterns ≠ Clean Code

Take 2

Well here we are, back again talking about clean code. I thought it would only be fair to introduce you to its evil counter part. Now that I really think about it, I really must be goo at these blogs because I am giving away the secret recipe to the perfect code. If you know how to write clean code BUT also know how to avoid bad patterns thats the ulntimate duo, nothing should stop you!

What is Anti-Pattern

it is how NOT to solve recurring problems in your code. Anti-patterns are considered bad software design practices, and they are typically ineffective or obscure fixes. They can lead to issues such as technical debt, where suboptimal code must be addressed and corrected later.

  1. Spaghetti Code:
    • Description: Code with little to no structure, making it difficult to follow.
    • Issues: Maintenance nightmare, challenging to add new functionality, and prone to breaking existing code.
  2. Golden Hammer:
    • Description: Overreliance on a specific architectural pattern or tool.
    • Issues: May lead to performance issues, difficulty adapting to different problems or languages, and inhibits learning and exploration.
  3. Boat Anchor:
    • Description: Leaving unnecessary or obsolete code in the codebase with the assumption that it might be needed later.
    • Issues: Causes confusion for developers, longer build times, and the risk of inadvertently activating obsolete code in production.

Why we might use it still

  1. Prototyping or Rapid Development:
  • In the early stages of prototyping or rapid development, the primary focus might be on quickly testing ideas or demonstrating concepts. In such cases, developers might use shortcuts that resemble anti-patterns to expedite the process. However, it’s crucial to revisit and refactor the code for production use.

Anti-pattern is a practice or solution that may seem like a good idea at first but, in reality, is counterproductive and can result in negative consequences for the software development process. It’s a term used to caution against common pitfalls and encourage developers to adopt best practices for creating maintainable, efficient, and effective code.

While there may be rare instances where the use of anti-patterns is justified, such as in prototyping, rapid development, or within legacy systems, it’s essential to recognize that intentional use of anti-patterns comes with inherent risks. These include technical debt, reduced code quality, and challenges in maintaining and scaling the software. I still encourage developers to prioritize clean code above all else.

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.

Is Agile Worth it for Non-Developers?

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. 


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.


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. 


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.

Writing Clean Code

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: 

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.

Code Documentation 101

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.


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 –

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.

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:

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.

Programming Etiquettes – 4 best practices

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.

Week 13 Clean Code

In my search for a topic this week, I searched for an article closely related to our homework and our last five Pogil activities. I kept it simple and looked for an article about clean code. I understand we have been loaded with tons of information about clean code but when was having more of something bad. I wanted to see different perspectives of clean code outside of class and what people inside the field or with experience opinions on. Allowing me to get insight from outside of class will be very helpful. Also, being able to have an open mind with coding can go a long way plus being able to see similarities with what I have learned and my own opinions. 

This article starts by describing the term “Spaghetti code” which refers to complex tangled code that is hard to decipher and causes frustration for everyone involved. This ties into clean code by emphasizing how is an integral component of software development and can only be maintained with practice. This comes with less team frustration and allows for any teammate to manage the code. Clean code is just not a statement of keeping the code tidy tightly but more of a form of communication that can be understood by everyone thoroughly. Software companies make big investments into clean code by hiring someone and paying them around $60-$100 an hour because of how vital it is for long-term success. An effective strategy to implement clean code is by grouping similar functions, utilizing whitespace, and “one idea per line” and “one action per statement”. To tie it all together your code must be consistent to adhere to agreed-upon team coding standards. Decisions that will help in the long run would be to add meaningful names, maintain simplicity, and apply comments effectively. 

With this article, I was able to learn a new term “Spaghetti code” that is self-explanatory and can remind me to keep my code simple and clean. I was able to connect many teachings from class including using meaningful names, abiding by team agreements, and utilizing whitespace. All these are valuable pieces in writing clean code that should always be in your mind when writing any piece of code. I was surprised at how much software companies invest in clean code and wasn’t expecting them to get paid that high. My main takeaway from the article was to keep my code consistent and simple. You may not think about these things but wanting to make things more complex can be a determent to all your previous work so being consistent will not only help you but your team as a whole.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

AI as a Tool for Software Development

Within the past few years, AI has really made a name for itself. Whether it be through art, music, chatbots, or whatever else AI can take part in, AI has cemented itself into our daily lives. One area in which AI has become an integral part of is in software development, transforming various aspects of the process.

One of the greatest features that AI brings to software development is the fact that it can assist in generating code and finishing code as developers develop. Using existing patterns in databases for code, AI can generate code according to what the developer is trying to achieve. Say a developer needs to create a function that checks if a number is prime, returning false if it isn’t and true if it is; if a function that meets these requirements exists in a database, then the AI will simply suggest that function. 

Although using AI in this way is very useful for developers, they also need to be able to develop without it. AI can suggest code but that doesn’t mean that said code will perfectly fit into the program or that it’ll suddenly work thanks to the AI’s help. At the moment, it should just be used as a tool to make the development process easier and faster; although we may see these features and much more in the future. 

Another way in which AI can assist in the software development process is through analyzing the project timeline, workflow, and other such data and making predictions based on them. By analyzing previous projects, sprints, and other data in the development process, AI could create some insight and predictions that the project managers could take into account when dealing with current and future endeavors. These insights may include timelines, potential highs, lows, bottlenecks, roadblocks, and other such information that the managers could use to optimize the workflow and avoid issues. 

As with the developers and generated code, project managers should also have knowledge of management. AI’s suggested timeline, insights, and all that aren’t guaranteed but simply ideas based on what has happened in the past. It, like for coding, should be used as a tool but in this case, it should be used to see and suggest things that the human manager may not have anticipated or seen.

Overall, AI can be very useful in the software development process but this doesn’t mean that it is the savior for all issues within it. Like with any field one goes into, having knowledge of the fundamental ideas and practices are necessary if one wants to succeed. AI, as of now, is still in its early stages compared to what it is capable of and should be used with caution. AI was used to help write this post and I hope to be able to use it fully both now and in the future whether in my career or outside of it.

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