Author Archives: Eli

Exposing Ignorance

While sometimes difficult, I found the practice of “Exposing your Ignorance” to be extremely important in many aspects of life, and naturally it makes sense that it applies to software development the same.

Understanding what is left to be done/improved upon is a core part of development and this rings true for anyone’s apprenticeship. If one cannot see what needs to be improved in their craft, they can subtly become too comfortable with one expertise causing them to never be able to achieve true master craftsman status by holding themselves back due to their complacency.

By asking yourself and figuring out what you are good at and what you are bad at it will allow for the greatest improvement along the apprenticeship journey. Having humility when learning is essential, you may try to fake it until you make it but that will only take you so far before too many errors or issues arise putting your overall proficiency and potentially your position in question. Accepting you are not going to know or understand everything allows for one to learn more efficiently and quicker by choosing to reach out for help when needed rather than forcing themselves to “figure it out”.

I also found it interesting that this practice shines importance on displaying your learning ability to your team. It’s important that if you don’t understand something it’s okay to speak up and let that be known since the team you’re a part of is most likely going to be understanding of your inexperience. One must remember, that their team members had to be in your shoes at one point to get where they are currently.

From my own experience, I learned the hard way that struggling alone is so much harder than just swallowing my pride and asking for help. It seems like obvious advice but generally, I can be stubborn and sometimes I can feel reluctant to ask for help. Sure there can be lots of gratification in solving hard problems on your own, but sometimes it takes way longer than it should to make a seemingly “easy” change. This is because an “easy” or routine task for the team you’re a part of might not be “easy” or routine for a new inexperienced member.

By asking questions I can and have avoided misusing my crucially valuable development time by not being afraid to admit I need help. Struggling alone is always going to be worse than reaching out since there are many more meaningful uses of said time instead of being drained unnecessarily. If you don’t take the steps to become informed and more well rounded then you will continuously bottleneck your development as a craftsman.

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.

Apprenticeship Patterns Introductions

After reading the apprenticeship pattern introduction and each of the chapter introductions, I found myself intrigued by the advice offered to newcomers entering the software industry. It fascinated me how the medieval craftsman model can be applied, and the concept of “seasons” of expertise can aptly describe the stages of one’s software development journey. I had never viewed the different stages of an individual’s career in the software industry as distinguished apprentices, journeymen, and masters. However, after reading the explanation for each stage/season, it makes a lot of sense and appears more applicable to the field than I had previously thought.

While not being identical to say a blacksmithing apprentice, individuals who are educated or have little experience within the industry are still apprentices with much to learn in the ever-expanding and diversifying field of computing. Understanding and recognizing this could potentially go a long way in aiding one’s development into becoming a journeyman and, eventually, a master craftsman.

I also found it interesting how Pete McBreen offers a specific distinction, he views being a Software Craftsman or Engineer as two mutually exclusive things when, from my perspective (and pointed out later in the introduction), the line between engineer and craftsman remains quite blurred. It is difficult to dictate exactly where being a software engineer or craftsman starts and/or ends.

While briefly looking over each chapter and reading their introductions, I felt reassured since I had encountered some of the advice I was reading before, reinforcing that previous mentors were knowledgeable in what they taught me. I was also struck with a feeling of my eyes being opened to new ideas or practices that I could employ to further my journey and hopefully help others in the future who may view me as a mentor, aiding them in their learning journey.

A particular part of the introduction (chapter 1) resonated with me deeply. Carol Dweck is quoted stating “effort is what makes you smart or talented,” a value I hold dear. I maintain the belief that anyone has the potential to excel in anything, but only those who put a lot of effort into learning and building their expertise are considered “smart” or “talented” in any field/profession.

Overall, I am looking forward to delving deeper into the good practices that will aid in furthering my learning and personal development, as well as contributing to the development of my peers, by being equipped with tools to help everyone succeed.

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.

Libre Food Pantry & Thea’s Pantry

I found the Code of Conduct from Libre Food Pantry interesting/useful as it provides a great framework for meaningful collaboration that is inclusive to as many people as possible. I chose to write about the Code of Conduct because I believe in the importance of moral coding/development and the Code of Conduct sets quite a few good standards for all contributors to follow. I also like how each level of conduct enforcement is clearly stated so if necessary, any individual may return to the Code of Conduct to clarify why or what may have caused a certain disciplinary action to come about.

I was looking through the Architecture section of Thea’s Pantry and I found searching over the full architecture of the Pantry interesting. I know that we touched upon mostly the GuestInfoSystem side of Thea’s Pantry last semester but relooking over the full microservice architecture was eye-opening since while being comprised of a couple of major systems I know my future may hold even more complex and interesting webbing of microservices. This makes me want to utilize the experience I will gain from this course to further prepare myself for any future projects or ventures I choose to embark on. By attempting to better familiarize myself with the architecture of Thea’s Pantry now, it will potentially help me and my team in the future by building a more robust understanding of the systems comprising Thea’s Pantry.

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.

From Learning to Doing

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:

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.

Should we still use SOLID Principles?

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:

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.

Work Smarter, Not Harder

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:

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.

Golden Rules for APIs

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:

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.

The Art of Code Refactoring

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:

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.

Patience is Key

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 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:

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.

First post!

Welcome to my little slice of the internet!

Hello, my name is Eli and I am currently a student studying to obtain a Bachelors in Computer Science.

This blog was originally created for my CS-343 course but updates may persist long after then.

A little about myself is I love all things gaming & tech, history, and basketball related. I enjoy FPS/Strategy games, learning about the past in-general, and going to NBA games while occasionally playing pick-up games in my free time.

This blog is mostly going to be software related but some posts may revolve around the aforementioned topics as well.

Thank you for viewing my blog and have a wonderful day!

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.