In another podcast from Stack Overflow again by Ben Popper with special guest Johnathan Schneider, discusses the nature of technical debt surrounding open-source projects. The main example used throughout the podcast is refactoring code, switching from java 7 to java 8. And in later examples sometimes java 8 to like java 17. As they explain the difficulty when switching, especially when more manual work is needed, talk about the ways technical debt is created. After more discussion around the software he made to help refactoring, goes into more detail about the nature of technical debt. We think of technical debt as something that we impose on ourselves. Like taking shortcuts or code that needs to be updated. One of the main points of this podcast is to think about technical debt more as maintenance. Obviously sometimes it is self-inflicted, but often it just comes with the territory. As new things come out, things will need to be updated. It’s easier to think of it as something that needs to be done for the sake of the health of the program. Rather than as something I did that I need to fix because of my own short sightedness. 

I chose this podcast because it is related to our discussions of technical debt and refactoring code. In class, we talked about the nature of technical debt and how often it is a code structure thing or maybe a breaking change. It is more thought of as something that comes as a result of not thinking ahead. While I think that is true in many cases. I think a lot of the time it can’t be avoided, like in the case of code versions. Thus it’s better to think of it as maintenance rather than something that could have been avoided. For me, mentally saying that this problem is something that couldn’t have been avoided is better. If I think it’s my fault then I feel like an idiot and get down on myself. Maybe it is just a mental thing, but it goes a long way for the mentality of a person or team. Another aspect of the podcast I think it is important to think about is how the open-source nature plays a part in this. Code is being worked on at all times, different people. So when the code is updated and your code no longer works. It’s important to realize that this isn’t your fault and just is the nature of things. The code not working is not your fault and just needs to be maintained so it works again.

Citations

https://the-stack-overflow-podcast.simplecast.com/episodes/open-source-ecosystem-reduce-tech-debt/transcript

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

In this podcast episode from Stack Overflow by Ben Popper with special guest Ryan Donovan, discusses the evolution of documentation and the future of technical writing. The whole episode is about the nature of writing documentation is changing fast. With the advent of generative AI and other tools like linters that can automatically write or run tests make technical writing more automated now more than ever. One of the first talking points is why documentation is being pushed a lot more now. Increasingly because programmers don’t like writing documentation this job is delegated to technical writers. Who will go into code repositories and write documentation.These technical writers end up being some of the most important people when it comes to code structure. Since they write the documentation that defines how the program is specified and built. 

After moving through some background information the next talking point is the future of technical writing. This was of the most interesting parts to me because it discusses not only just the AI aspect, but things like how other tools play a role. The question then becomes will AI replace technical writers? The answer they concluded was no. Although it is able to generate and automate documentation. Often that documentation needs to be looked over. For the moment AI is not able to create fully functioning documentation to that level yet.

I chose this podcast because it directly relates to what we have been doing in class lately. Looking at the Open API yaml and documentation related files. I don’t think there is a specific lesson to be learned from this podcast. More about just thinking about the future of technical writing. As programmers, we will all have to interact with documentation at some point. Whether that be something like java docs or yaml files. I think it’s important to know what goes into making documentation and the people who write. Because it really is a career all in of itself. Like I mentioned before, one of the most interesting aspects of technical writing is how AI is changing the landscape. Like many areas right now, people are worried if their jobs are in danger. I think with a lot of other cases human supervision is still needed. Another point that I didn’t really think about before now is the importance of documentation other than just information. Like in the case of yaml files that define structure. Is how important it is because it literally specifies how software operates. Like the definitions of endpoints that must be fulfilled and other specifications.

Citations

https://the-stack-overflow-podcast.simplecast.com/episodes/your-docs-are-your-infrastructure/transcript

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

RESTful APIs are a common and standard structure used to develop software applications. Lately in class we have been delving into how these APIs work using Thea’s Pantry as an example. I found this blog that gives a concise and easy to understand explanation of REST works. He gives a brief overview of what REST stands for and then explains its purpose. It used to make data transfer between client and server easier and more encapsulated. One of the points that was interesting to me and made a connection to what we learned in class about coding principles. The principle of encapsulation and keeping things as independent as possible. Trying to keep the server and client as independent as possible to make scalability and maintenance more efficient. The REST API serves as an interface between client servers that serves to communicate for them so they don’t have to.

It then goes into more detail about resources and URLs and return formats. It was also interesting to me that return formats could be more than JSON, the example they used was XML. You just have to specify, but I don’t know a reason why you wouldn’t use JSON. The Reason I chose this blog is because it is a simple explanation of what REST API is. For me personally, APIs can be kind of hard to understand, but this blog explains in a way that makes it easy to understand. The picture was a big help. Other than that I don’t really have anything to say. 

https://medium.com/@MakeComputerScienceGreatAgain/understanding-rest-api-a-comprehensive-guide-52fc10f6c9ed

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Estimation is a huge part of software development. It exists in many aspects of our work. The area where it is most important is estimation of development time. Many software methodologies are reliant on breaking down work into smaller parts and creating workflows. Like the famous Sprint from Agile. A common theme among all of these is estimating the time it will take to complete these tasks. And on a larger scale, how long it will take to finish a feature or product.

In this blog by Yaakov Ellis, discusses the importance of estimation. Moreover, the skills needed to make a good estimate. He first discusses the usefulness of estimation. How good estimates increase efficiency and reduce crunch time. One of the most important points of the article is the prerequisites needed to make good estimates. Such things like good and detailed specifications and understanding functionality. A point that stuck out to me is that he says that the people who do the work should do the estimates. Seems like something obvious but needed to be brought up nonetheless. There were many other points like not giving in to outside pressure to give an estimate that was unrealistic.

I chose this blog because a lot of what we talked about in class was teams deciding how much time to spend on certain things. Not only sprint lengths, but every part of Agile. Estimating the length of the project to even just a simple bug fix could take. I think it is a skill that is often overlooked. As someone who is bad at giving estimates and gives in to pressure to please people. I think that is something I will think about when making these decisions more. Some last points that I liked was the idea that you should estimate the public so everyone on the team can see them. I think that would decrease the risk of bad deadlines that force crunch on developers. 

Citation

https://stackoverflow.blog/2019/10/23/why-devs-should-like-estimates/ 

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.