Author Archives: Lord Zed

Your First Language

The pattern I chose to explore is called “Your First Language” from Chapter 2, which focuses on the importance of choosing a primary programming language and developing proficiency in it. The pattern addresses a common concern for many aspiring software developers: the fear that job opportunities and success are contingent upon mastery of multiple programming languages. However, the pattern provides reassurance by emphasizing the significance of selecting a language and becoming fluent in it. This chosen language will serve as the foundation of your early career, and investing time and effort into mastering it will yield fruitful results.

I found this pattern particularly relevant to my own journey as a computer science student. Like many others, I have dabbled in multiple programming languages during my studies. However, this pattern reminded me of the importance of honing my skills in one specific language, rather than spreading myself too thin across various languages. By dedicating myself to one language, I can truly delve into its intricacies, best practices, and development tools, allowing me to become more proficient and confident in my abilities. For me, that language has been Python (and R to a certain extent). I found in my Senior year, that focusing on Python has allowed me to gain more proficiency and has helped me massively with data analysis and classification for my Data Capstone class as well as my summer fellowship project.

Furthermore, the pattern emphasizes the value of seeking guidance from experienced developers. Collaborating with a mentor who can offer insights, guidance, and occasional support can significantly accelerate your learning and help overcome obstacles. However, it’s essential to strike a balance between seeking assistance and independent problem-solving, as the latter fosters personal growth.

In conclusion, the “Your First Language” pattern serves as a valuable reminder that proficiency in one well-chosen programming language can lay the groundwork for a successful career. By dedicating ourselves to mastering that language, working on small projects, and seeking mentorship, we can enhance our understanding, confidence, and employability. I am excited to apply the lessons from this pattern to my own professional development, and I encourage fellow aspiring developers to do the same.

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: The Deep End

The Deep End is an important pattern to consider in any profession, especially in computer science. It reminds us that the only way to grow and improve our skills is to take on new challenges that may be outside of our current abilities. This can be daunting, but it is essential to keep pushing us to continue learning and improving.

One aspect of this pattern that I found particularly useful is the suggestion to break down tasks into smaller, more manageable pieces. This not only helps to make the task seem less overwhelming, but it also allows us to focus on making small incremental progress over time. By taking small steps towards a larger goal, we can see tangible progress and stay motivated throughout the process.

Another important point made by the pattern is the need to seek help and guidance from more experienced colleagues. It can be easy to feel intimidated or embarrassed to ask for help, but it is crucial to remember that everyone starts somewhere. We all have areas where we can improve, and seeking help from others can provide valuable insights and guidance. By doing so, we can learn from the experience of others and apply it to our own work.

Overall, I found The Deep End to be a helpful and thought-provoking pattern. It has reminded me of the importance of continually challenging myself to improve my skills and to seek guidance and support when needed. As I continue on my path as a computer science apprentice, I plan to keep this pattern in mind and take on new challenges whenever possible.

However, I do believe that there is a balance to be struck when taking on challenging tasks. While it is essential to push ourselves to grow and develop new skills, it is also crucial to be mindful of our limitations and not take on more than we can handle. We need to be responsible for managing our own risk and taking steps to minimize it where possible. Overall, I believe that The Deep End is an important pattern to keep in mind, but it should be approached with a balanced and mindful mindset.


From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

In the early stages of a career, it is quite natural to feel like you don’t know enough and to be intimidated by the tasks ahead. As an apprentice, you may feel like you have to prove yourself to your colleagues and bosses, which often leads to pretending to know more than you actually do. However, pretending to be an expert can lead to disastrous results and can harm the project in the long run. The “Expose Your Ignorance” pattern is a solution to this problem that many apprentices face.

The “Expose Your Ignorance” pattern emphasizes the importance of being honest about your lack of knowledge, especially when it comes to software development. Being transparent about your ignorance is a sign of strength, not weakness, and it allows your team members and managers to understand the scope of your abilities. This pattern encourages apprentices to admit their lack of knowledge, ask questions, and share their learning process with their team.

What I found interesting about this pattern is that it highlights the importance of transparency and honesty in the workplace. It also emphasizes that software development is a continuous learning process, and everyone is constantly learning. There is no shame in not knowing something, and it is better to admit it and ask for help than to pretend to know everything. This pattern encourages a culture of openness and collaboration in the workplace, which can lead to better team performance.

This pattern has caused me to change the way I think about my intended profession. As a future software developer, I now understand that it is okay to not know everything and that I will constantly be learning throughout my career. I have also learned that it is essential to have an open and collaborative culture in the workplace, where everyone feels comfortable sharing their knowledge and learning process with others. It is this openness that will foster innovation and lead to better results.

However, I do disagree with one aspect of this pattern, which is the suggestion to put a list of things that you don’t understand in a place where others can see it. While it is essential to refresh the list frequently and work on improving the listed skills, I don’t think it needs to be public. I believe it is enough to have the list for personal reference and accountability. Nevertheless, the core idea of exposing your ignorance and asking questions to learn is vital and should be practiced regardless.

In conclusion, the “Expose Your Ignorance” pattern is an essential tool for any apprentice in any profession, especially software development. Admitting your lack of knowledge and asking for help is a sign of strength, not weakness, and it fosters a culture of openness and collaboration. By adopting this pattern, you will not only improve your skills but also build stronger relationships with your colleagues and team members.


From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Chapter 1 and more

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Technical Debt

Technical debt is a programming theory that refers to the necessary work that gets delayed during the development of a software project to meet a deadline or deliverable. It is an idea that shortcuts are taken to quickly deliver a product, but this decision incurs a “debt” that must be paid in the future when the work is eventually completed. Technical debt is often the result of a tradeoff between perfect products and the short timelines often required for product delivery. Developers may choose the easier route with messier code or design to deliver a product faster, but this can lead to technical debt that must be addressed later.

Technical debt can accumulate “interest” over time, increasing the difficulty of implementing changes and leading to software entropy. It is important to manage technical debt to avoid these negative consequences. This involves identifying technical debt, accounting for nonfunctional requirements, and implementing best practices and agile practices to minimize it. It is also important to be proactive in reducing technical debt in new initiatives by carefully planning and designing projects from the start.

I selected this post because I wanted to learn more about technical debt as I found the concept to be particularly interesting and relevant to my future projects. This topic also seemed important as I found it amazing that despite the large file structure for projects in this class, it was not too difficult to add and update code for the assignments. That showed me how a codebase can avoid technical debt to a degree, and how it simplifies for maintainers (or a group of students) the process of adding and updating code to the codebase. After reading through the blog, I gained a better understanding of what technical debt is and how it can accumulate over time. This really resonated with me as I can see how important it is to consider the long-term implications of the decisions, we make during the development process. One of the most valuable takeaways for me was learning about the various types of technical debt and how to identify them. This will be especially useful as I continue to learn and grow as a programmer. I also appreciated the discussion of best practices and agile practices for managing technical debt, as I can see how these approaches can help to minimize the amount of debt that is incurred. I expect to apply what I learned in my future practice by being more mindful of the potential impacts of my decisions and actively working to minimize technical debt whenever possible.




From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.


KISS is an American rock band formed in New York City in 1973. The band is known for its elaborate stage shows, which often feature pyrotechnics, fire breathing, and other special effects, as well as the use of makeup and costumes by the band members. In all seriousness…

The KISS principle, or Keep It Simple, Stupid, emphasizes the importance of simplicity in design and systems. By keeping things simple, you can better understand and meet the needs of customers and create products that are more user-friendly and effective. In the world of software and technology, the KISS principle is especially important, as people often have many options to choose from and may not understand complex technology. By following KISS, you can build a minimal viable product (MVP) that allows you to confirm or disprove your hypothesis with minimal work and deliver your product in a straightforward way that is easier for users to understand. Amazon, for example, lists the KISS principle as a core leadership principle, stating that leaders should always find ways to simplify. When designing, it is important to wireframe religiously, use universally understood concepts, and avoid distractions. By following KISS, designers and developers can create products that are more efficient, effective, and user-friendly, and that are easier to maintain and update over time. The KISS principle is often applied to the design of systems and user interfaces, as well as to the development of code and algorithms, to create products that are intuitive and user-friendly.

I selected thispost because I have always been interested in the principles of good design and how they can be applied to create better code as a result. The KISS principle is a concept that I have heard of before in other classes and especially in the Robotics class last semester. I wanted to learn more about this principle and after reading this post was impressed by the emphasis on simplicity and how it can lead to better products and user experiences. The post also focused heavily on real world applications and its outcome which helped me visualize it better. I found this material to be very informative and made me think about how I can apply the principles of simplicity and user-friendliness in my own projects and for other CS classes in the future. I expect to use what I learned from this resource in my future practice by being mindful of the KISS principle and always striving to create products that are simple, efficient, and user-friendly.




From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Software Development Approaches

A software development approach is a methodology that is used to guide the processes involved in the development of a software system. Different software development approaches provide different ways of organizing and coordinating the activities and tasks involved in the development of software. Some of the most common software development approaches include Agile development, Extreme programming (XP), Lean development, Test-driven development (TDD), and Waterfall model among many much more. These are just a few of the many different approaches to software development. Each approach has its own unique set of principles and practices that help guide the development process and ensure the successful delivery of high-quality software.

Agile development is a software development approach that emphasizes collaboration, flexibility, and continuous improvement. Extreme programming (XP) is a software development approach that emphasizes collaboration, simplicity, and feedback. Lean development is a software development approach that emphasizes the elimination of waste and the continuous improvement of processes. The Waterfall model is a software development approach in which the development process is organized into distinct phases, and each phase must be completed before the next phase can begin.

Test-driven development (TDD) is a software development approach in which tests are written for a new piece of code before the code itself is written. The goal of this approach is to ensure that the new code meets the required specifications and behaves as expected. In TDD, developers write a test that defines the desired behavior of the new code, and then they write the code itself. Once the code is written, it is run against the test to see if it passes the test. If it does, the code is correct and is ready for integration with the rest of the system. If it does not, the code is revised until it passes the test.

I selected thisblog post because I am interested in learning more about Test-driven development. After reading this blog post, I learned about the principles and practices of TDD and how it can be applied in the software development process. I also learned about the steps involved in TDD, including writing a test that defines the desired behavior of new code, writing the code itself, and running the code against the test to see if it passes. I found this process to be logical and straightforward, and I can see how it would be a useful approach for ensuring the quality of new code. I made use of this method (to a degree) while working on the homework assignments for this class. I believe that it significantly simplified the process as having a set goal in the form of tests, made it easier to update/ add code that will work with it. Overall, I found this blog post to be very informative and useful. I learned a lot about development approaches, and I plan to use them for my future projects.



Top 6 Software Development Methodologies

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Backend developement

Backend development is an essential part of creating a dynamic, interactive website or application. The backend, also known as the server-side, is the part of the website or application that manages the data and logic behind the scenes. It works in conjunction with the frontend, or the client-side, which is what users see and interact with.

There are several components that make up a backend, including a server, an application, a database, and an API. The server is the physical location where the website or application is stored and accessed. The server is responsible for hosting the website or application and delivering it to users when they access it. The application is the actual software that runs on the server and provides the functionality of the website or application. It is typically built using a programming language, such as Java or Python. The database is where the data for the website or application is stored. The database is used by the application to store and retrieve data, such as user accounts, information about products or services, and other data needed by the website or application. The API, or application programming interface, is a set of protocols and tools that allow different software applications to communicate with each other. In the context of backend development, the API is what allows the frontend and the backend to communicate and exchange data. For example, when a user interacts with the frontend of a website or application, the API allows the frontend to send requests to the backend and receive responses with the relevant data.

I selected this post because I am interested in learning more about backend development and how it plays a role in creating interactive websites and applications. Furthermore, a lot of work for this class went into writing code for and experimenting with, the backend code for Thea’s Food Pantry. Working on something actively in use, even without making any changes, was a very interesting experience and will be immensely useful for the capstone class next semester. Understanding the importance of the backend and how it works with the frontend will allow me to better plan and implement the overall architecture of a website or application. Additionally, learning about the various backend components and their functions will allow me to make informed decisions when choosing technologies and frameworks to use in my projects.




From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.


Refactoring is an important concept in software development that refers to the process of modifying and improving the internal structure of existing code without changing its external behavior. This can be a useful technique for improving the readability, maintainability, and performance of a codebase, and it is often an essential part of the software development process.

There are many reasons why a developer might choose to refactor their code. One common reason is to improve the readability and understandability of the code. Over time, as a codebase grows and evolves, it can become difficult to understand and maintain. Refactoring can help to clean up the code and make it more organized and easier to read. Another reason to refactor code is to improve its maintainability. As a codebase grows and changes, it can become more difficult to make updates and modifications without introducing bugs or breaking existing functionality. Refactoring can help to make the code more modular and flexible, which can make it easier to make changes and updates without breaking the code. Refactoring can also be used to improve the performance of a codebase. As code is written and optimized, it can sometimes become inefficient or slow. Refactoring can help to identify and remove bottlenecks, and to optimize the code for better performance.

I chose this blog post on refactoring because it is a crucial concept in the field of computer science. As I read through the post, I found it to be very informative and well-written. The post clearly explained what refactoring is and described the various benefits it offers, such as improving readability, maintainability, and performance. I found the discussion of different techniques for refactoring code particularly interesting. Techniques like extracting methods or functions, renaming variables and functions, and restructuring code can all be effective ways to make code more modular, readable, and maintainable. I also appreciated the emphasis on maintaining the external behavior of the code during refactoring. This is something I will keep in mind as I continue to learn software development. Although refactoring wasn’t required in this class, I plan to use what I learned on future projects and when working with others on a team. I will refer to this resource as I continue to improve my skills and knowledge in the field.



From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Unified Modeling Language (UML)

Unified Modeling Language is a standardized language to visually represent software construction, design, and architecture. UML designs are process independent, and often omit irrelevant, or insignificant relationships and attributes in favor of simplicity. UML diagrams can be used to represent a variety of things in several ways. UML diagram can be classified into two main categories: Structure Diagram, and Behavioral Diagram.

Structure diagrams show the structure of objects and the relationship/interaction between those objects. Structure diagrams are to be considered descriptive and behave like a blueprint for the code, i.e., it can be used to inform the design of written code. Class diagrams are one of the most frequently used Structure diagrams in software development. It shows each of the classes in a system with their attributes, class methods or operations, the scope of every attribute and method within a class, and the relationship between two or more classes. A class diagram has three parts: Class Name, Attributes, and Methods. The name of the class is always at the top, while any attribute like a variable is in the middle. A note can be added pointing to the attribute to show any individual specification or requirement. The methods are listed at the bottom and can similarly have notes pointing to the method to show any individual specification or requirement. Arrows are used to describe the relationship between two or more classes. Depending on the arrow the specific relationships can be identified. The various relationships are Association, Dependency, Implementation, and Inheritance.

Behavioral diagrams show the intended function of the system and any objects it contains. They describe how those objects should interact with each other to make the system functional. Behavioral diagrams are considered prescriptive, i.e., they show how the written code should work in the system.

As a CS student, I found thisblog post on UML diagrams to be highly relevant and useful. Homework 1 and Homework 2 provided a great opportunity to delve into the complexities of these diagrams and gain a deeper understanding of their various properties and concepts, especially for Class Diagrams. It will very likely be useful in future classes as UML diagrams allow you to be able to communicate your design ideas effectively to other members of your group, ensuring that everyone is on the same page and working towards the same goal. They can also be a valuable resource for documenting and maintaining software systems, making it easier to understand and modify the system as needed. For example, the visibility of attributes and the connections between classes, as represented by arrows, are crucial elements that contribute to the overall coherence and functionality of UML diagrams. Additionally, the provided examples helped to clarify and illustrate these concepts in a clear and concise manner.




From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.