This week I was searching for an article to write about and I stumbled upon an article from Codecademy sharing the story of Juan Paredes, a Full-Stack Engineer from Mexico. The article is an interview of sorts where Juan has responded to prompts related to his journey from a Call Center Supervisor to a Full-Stack Engineer.

Juan covers how exactly he got into software engineering. When first moving to Mexicali, Mexico he got a job as a call center specialist. After 3 years Juan was promoted to Operations supervisor where at this point he decided to expand on his love for computers and wanted to start learning how to code through a free course on Codecademy.

After completing the free course, Juan decided to pay for a subscription and before Juan was completed with his first paid course, he was able to find an entry-level developer position. After figuring out that software engineering is what he truly wants to do, he also started attending the Mexicali Institute of Technology and is currently studying to obtain a degree in Software Engineering.

Juan also talks about how limited time and a pay cut made things temporarily more difficult but between his passion and determination, Juan continues to learn and progress.

When the article was created, Juan had just found a job with better pay and benefits than his first position and continues to progress forward in the software field.

Juan finishes off his remarks by recognizing the importance of organization and being open to learning new things as traits that will carry you far in the field. With organization, one can more easily find how to and be able to implement changes and by keeping an open mind you may learn things that while not valuable at the present, could become of great use in days, weeks, or months later on.

After reading this article I wanted to share and reflect upon it since I could relate to Juan. I too discovered my interest in programming through another medium of computers, however mine was video games. I started my journey by wanting to learn how to script in Lua for Garry’s mod addons and after that, I gradually kept learning more about coding. I never saw it as more than a hobby at the time, but here I am today almost finished with my Bachelor’s in Computer Science and preparing to join the workforce soon. Juan’s story serves as a reminder that through determination and perseverance, I can learn and do whatever I want within the extensive computer science field after obtaining my degree. It may take time, but in the end, the hard work will pay off regardless of how hard it may be or how much I would want to give up.

Article Link: https://www.codecademy.com/resources/blog/from-call-center-sales-representative-to-full-stack-engineer/

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.

While I was perusing for an article to write about this week I found this interesting blog post posing the question, “Why SOLID principles are still the foundation for modern software architecture”. The post is written by Daniel Orner, a Software engineer from the likes of Flipp and formerly IBM.

Daniel starts by explaining what exactly is “SOLID”, he attributes the meaning of SOLID to “the writings of Robert C. Martin in the early 2000s” which provided a framework for creating quality object-oriented programs.

Daniel then covers what has changed since the 2000s but also what hasn’t. Things that have changed are the popularity of scripting or dynamic languages has risen greatly, some facets of object-oriented programming have become meshed with functional programming, open source software has become extremely popular, and microservices have seen massive growth in use since the 2000s.

However, things that haven’t changed are that programs are still written and modified by people, there is still a form of organization/separation of code regardless of the language used, and code can be used for either internal or external purposes. I believe that all of these facets of programming may never change no matter how much time passes. Even with the advancement of AI, I still believe that the human factor in programming will always be important. When faced with potential moral or ethical problems, a human element would always result in a better outcome than an AI could/would.

Daniel then goes through each of the five principles and alters them to become more general and applicable to modern programming trends. He starts by altering the single responsibility principle to “Each module should do one thing and do it well.”, the open-closed principle to “You should be able to use and add to a module without rewriting it.”, the Liskov substitution principle to “You should be able to substitute one thing for another if those things are declared to behave the same way.”, the interface segregation principle to “Don’t show your clients more than they need to see.”, and finally he left the dependency inversion principle as is!

Daniel then wraps up his post concluding that modern SOLID is ensuring that your code is not surprising or confusing to anyone who will use or work with it, keeping things reasonable, and properly organizing said code. Reiterating that SOLID is still key to creating and maintaining well-written code.

Overall, after reading Daniel’s post it allowed me to widen my view and understanding of the solid principles. After comparing his new definitions to the ones crafted by Robert Martin, it showed how well thought out SOLID principles were to be able to last 20+ years already and remain relevant for plenty more to come. The SOLID principles offer a framework not only for object-oriented programming but programming in general and Daniel showed this impeccably just by changing a couple of words in the definitions while keeping the same meanings given to the principles back in the 2000s.

Article Link: https://stackoverflow.blog/2021/11/01/why-solid-principles-are-still-the-foundation-for-modern-software-architecture/

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.

This week I was viewing the syllabus topics and found a short article written by Rosie Faulkner, LAMP stack developer, where she describes the principle of least knowledge relating to software development.

Rosie coins the principle of least knowledge as “One of the most important software design principles” and defines the principle as “loose coupling, in that your code or your class depends on the least number of other classes in order to function.”

Rosie also states that the principle’s main focus is modularity and that a code’s modularity is important as to reduce the chances of code becoming overly complex/opaque and/or causing naturally occurring errors to become a frequent issue. By keeping our code as simple as possible, developers can create and maintain code while being more confident that new changes or updates will not affect/break anything. The less dependent (where possible) your code can become from third-party libraries the more secure and clear your code becomes overall by allowing others to view what is being done directly versus having to familiarize themselves with a new library.

By following the principle of least knowledge a developer can avoid their code from becoming Rigid, Fragile, Immobile, Overly Complex, and/or Unclear (or Opaque). By restraining from using third-party code, you can reduce the reliance on outside systems (where possible) which in turn will help not only yourself but also others in being able to view and understand your code directly. This will allow everyone to meaningfully contribute to whatever the project may be since all will have a proper understanding of what is being done.

An example where this can be displayed, given by Rosie, is a class that allows you to locate a user’s country using the IP of the given user. Rosie states “You could use a third-party class to do so” but security may become an issue over time and unsuspected updates may cause outages resulting in downtime and/or errors for users. Instead, if you create your method to return a user’s country you can directly change and update the code as needed and be able to view and tweak code with more transparency.

I often find when I am coding that I tend to over-complicate whatever I am trying to do. One example would be looking for ways to work around creating functions myself by using external systems instead. After reviewing this article, It’s more prevalent to me that trying to create the least amount of lines for a block of code doesn’t always relate to the health of the code as well. By taking a step back and reviewing what I am trying to complete and what remains to be done, I will be able in the future to partition which code should be used and what should be refactored to create the most healthy and maintainable coding environment possible. This will save me from future headaches due to negating the risk of unexpected changes/updates breaking things.

Article Link: https://medium.com/@faulknerproject/the-principle-of-least-knowledge-in-software-development-499b7a28aa14

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.

This week I have decided to view a source regarding APIs since that has been our focus in class recently. I had come across an article written by Jordan Ambra, an experienced software engineer from Pennsylvania, describing a few “rules” to keep in mind to create the best API possible and better maintain its health in the long run.

Jordan starts with his first point being proper documentation, he states “ask [a developer] to follow a tutorial or build something really basic in about 15 minutes. If they can’t have a basic integration with your API in 15 minutes, you have more work to do.” It’s important to have proper documentation because without such, having an expansive and robust API is great but what isn’t great is if the implementation of said API is very limited caused by developer confusion due to the lack of documentation.

The next point Jordan describes is the importance of API stability and consistency. This is key in having APIs last in the long run. Jordan uses Facebook as an example to show that while an API’s health won’t make or break a company, most people don’t have the capital or userbase Facebook does so recreating an API is going to be more costly for one person. Keeping track of version numbers by incorporating a change log is a great way to document changes so users know how and why to upgrade.

Another practice is to maintain API flexibility, if an API is or over time becomes too rigid it can cause integration to be difficult. Not all platforms are consistent, Jordan states, “It’s good to have at least some degree of flexibility or tolerance with regard to your input and output constraints.” So by keeping the API flexible, it’ll allow for the widest implementation without a large margin of error.

A very important aspect of APIs to prioritize is security. With malicious actors always looking for new weaknesses and ways to hijack or manipulate things for their gain, it is more important than ever to implement security safeguards to act as a preventive measure to prevent people with the wrong intentions from harming others.

Finally, the last thing Jordan brings up is the importance of an API’s ease of adoption. If things are overly complex or not universal enough it can turn people away from wanting to interact with your API. If you’re not able to efficiently use your API then how is anyone else going to be able to?

After reading this article, I hope to now be better equipped to create healthier and longer-lasting API(s) among a majority of APIs that are not easy to use which can be due to one, a combination, or all of the factors above. Focusing and prioritizing the rules set by Jordan will help in the future to improve my work.

Article Link: https://www.toptal.com/api-developers/5-golden-rules-for-designing-a-great-web-api

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.

Since we have been discussing refactoring in class recently, it got me interested in finding out more about what makes refactoring… well “refactoring”. I found this interesting article “Refactoring vs. Defactoring” by Nicolas Carlo, a French-Canadian Software Engineer, which describes the difference between refactoring and debugging while also introducing the idea of “defactoring”.

The article starts with the definition of refactoring, which according to Martin Fowler, is “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior“. In simpler terms, refactoring is all about tidying up the interior of a program while keeping the exterior the same.

Nicolas is clear however that fixing a bug, adding features, or changing features is not refactoring but points out the importance of refactoring code before altering the functionality of a program.

Nicolas states that in his experience things that can help with solidifying this distinction are to, start doing distinct commits separating both refactoring and change commits, make commits more frequently, prefix commit messages with R or C to specify the change(s) made, and learn how to use automated refactoring to improve the health of one’s code.

Nicolas also explains by following these practices he feels as if his work has become much safer and simpler than before. With his newfound awareness, he feels as if he can put the best quality into his work. He also gives a brief rundown of how thinking of Refactoring and Changes as two hats you wear when programming can also help increase developer awareness.

While we discussed refactoring, I thought it was interesting how Nicolas framed defactoring as an opposing process to refactoring in the title of the article but I came to find out it is not that at all. Defactoring is described by Nicolas as “cognitive refactoring” which is done by making the code less abstract in places where abstraction is no longer required.

He says that when working with legacy code, he notes some items such as temporary variables that are just not needed in places where they were necessary in the past. By altering code to remove such variables, Nicolas signifies this process as “defactoring” since it removes old abstractions that just are not needed anymore.

After reading this article I feel as if I have a stronger newfound understanding of the importance of separating refactoring from normal changes since it can make a dramatic difference in a program’s overall transparency. In my work alone, I have realized the importance of taking on one aspect at a time improves the cohesion and efficacy of the final product, but I never really thought about the importance of distinguishing changes and refactoring. Trying to be aware of this in the future will help me create the best version of my work possible by ensuring I have a more robust knowledge of a program’s behavior and added transparency of said program through my code alone.

Article Link: https://understandlegacycode.com/blog/refactoring-and-defactoring/

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.

Over the weekend, I spoke with a retired Electrical Engineer, Bob. While we were chatting the topic of software somehow came up and the difference between today’s programming versus it’s past. We discussed how much things have changed from the 1960s to the present day. Bob had gone to WPI in the mid to late ’60s and was an Engineering Major. He enjoyed math and naturally gravitated toward the Engineering field but one day he realized how utilizing programs could help him compute highly complex math problems. Like everyone, he had to start his journey somewhere and the best language that seemed suited for him at the time was Fortran. Fortran is a very old language and I honestly didn’t know much about it, past that it was created at the time of punch cards and operators who compiled your programs for you. Bob would place his punch cards into a mailing box marked with the last 3 of his social. He said if he was lucky, the next afternoon the code was run. Normally, he said it would take about 2-3 days before getting your results back. Once returned, say if there was a period instead of a comma, a message would say “Program Terminated” or something along that. This is when the debugging process begins by carefully examining the code above the “terminate” message. Once the issue was found, he would fix it and then start the waiting process all over again. Today, we can run code in seconds, be able to debug and fix code in minutes, then re-run the code again. I’ve spent 6 hours in the past incrementally fixing and building a project for class and looking back I have a newfound appreciation for the tools and languages that aid us in programming today. But this made me think, what is Fortran and how was it used? To my surprise, while being a language seemingly in limbo, there is still a strong community surrounding the language. I found this article on Medium.com detailing a year’s journey attempting to revitalize and attract new programmers to Fortran. Over that one year, work had been done to implement a better-improved standard library (stdlib), a lot of focus and progress was being made into creating a Fortran Package Manager (fpm), and a website was used to bring the community together while also to help retain new learners instead of letting them struggle alone. While the modernization of the language still has some ways to go, the patience and commitment from the contributors to the stdlib, fpm, and website just show how patience is key to creating the best possible end product. This reminds me of the saying “Slow is Smooth and Smooth is fast” which resonates with software developers since the moment you rush yourself is when things end up half-baked and many issues arise. I should take my time more, that way I could catch small mistakes that can potentially snowball into more complex issues.

Article Link: https://medium.com/modern-fortran/first-year-of-fortran-lang-d8796bfa0067

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.