AI has a polarizing reputation in many practices such as art, music, and coding, and seeing as you can make copies of works based on recorded patterns in less than half the time, it is understandable why people can dislike it. I like AI, it can generate funny images, make trivial tasks instant, and provide more input for someone trying to improve in a field. In coding, AI is a worrying topic that has the potential to replace many humans in the industry. However, AI is only as good as its user, a user that isn’t knowledgeable in the the product they are trying to generate cannot be as good as someone good at the field. 

In “Three Types of AI-assisted Programmers” by Isaac Lyman, the post covers the three types of people who can use AI in programming. Those three are someone with no coding knowledge, a junior engineer, and a senior engineer. The author covers the pros and cons of each person using AI to code and expresses the opinion that AI is a great addition to a team’s work, if they are attentive enough to the code generated. The pros and cons of the junior and senior engineer is what I want to highlight since AI could very well be integrated in future developer teams. The author mentions that junior developers should stray away from using AI in their work, as it may become a crutch. Rather than using AI to fulfill work tasks, junior developers should use AI to provide insight and examples to improve their skill set. A senior engineer, already having the fundamental code skills and knowledge, should just leverage the speed that AI can provide into streamlining basic code. By saving time from the menial code, senior engineers can put more time into delivering better features.

I thought this blog post contained valuable insight into the use of AI in coding and future development teams. The exploration of pros and cons for each category offers a valuable roadmap for future developer teams, emphasizing the need for a balanced and strategic integration of AI into the coding workflow. As AI continues to improve, it becomes clear that the use of AI, particularly for junior developers as a learning aid and senior engineers for time optimization, holds the key to coordinating between human expertise and artificial intelligence in the evolving landscape of coding.

Reference: https://stackoverflow.blog/2023/12/11/three-types-of-ai-assisted-programmers/

From the blog CS@WORCESTER – Leon's Blog by llai194 and used with permission of the author. All other rights reserved by the author.

Before taking this class, I didn’t know of any guidelines for writing code. Clean code is a guideline with an objective to make code easier to understand, maintain, and read. By following its principles, a developer makes projects more likely to succeed in the long term. Learning this, I thought that I should try to implement this in all I code I make, and am still trying to make clean code practices common in my code. However, in a blog post: “Goodbye, Clean Code” by Dan Abramov, he says to “let clean code guide you, then let it go”. This was interesting, since wouldn’t having clean code all the time be nice to have for understanding the code you write? Dan during the time he recalls in the post thought so too.

In this post, Dan recalls a time when he was working on a project and checking his colleague’s code they had just turned in. The code had tons of repetitive code and math that would take a second to process. Bothered by this, he fixed it to look cleaner, removing the repetitiveness and making it so there could be changes in one spot rather than multiple methods. This resulted in a request that he reverts the changes he made from his boss, which he reluctantly agreed to do. Looking back at this event, the author says it took years to understand his boss was right. Calling clean code a phase of a coder’s life and explaining that chasing that guideline was forgetting about the human aspect of coding. Firstly, he changed his colleague’s code without discussion, which was a terrible decision when working in a team where they needed to collaborate. Secondly, he realized later that the changes he made would have impacted the project severely and added complications if he had kept them.

This blog post was not saying there was a problem with clean code itself, but how people treat clean code as an absolute guideline like the author did in the past. This post helped me understand chasing clean code is more of a detriment to yourself and others on your team and to not get too obsessed with it. Getting hung up on this aspect makes you lose sight of your project and team’s goals in mind. I think that people should keep writing clean code but not lose themselves to chasing a standard in a way that makes writing that code meaningless. While I haven’t experienced this, I can sort of understand it as how I was trying to implement these principles in my code after learning of them.

References: https://overreacted.io/goodbye-clean-code/

From the blog CS@WORCESTER – Leon's Blog by llai194 and used with permission of the author. All other rights reserved by the author.