Ayden McCall

My Programming Journey

I began my programming journey in 2020, though I was interested in software since I was young. I've always found myself interested in the unique ways that programming forces you to think. One of the first really interesting concepts I ran into when first learning object-oriented principles was a concept Martin Fowler calls, "tell don't ask" (Fowler, 2013). This concept demands that we stop thinking of programs in the most literal, direct way that may seem natural at first, and consider the architecture of how we build software. You can build a house without following regulations and it may stand, but when something unexpected happens, you'll realize those regulations exist for a reason. I simply love the unique conundrums and solutions software creates.

One of the most important things I've learned over the years in the importance of managing your technical debt. It's an unfortunate reality that as a developer, You will not always have time to work on what you need to. While it would be great if we could do everything perfectly the first time around, it's not always clear what the best path forward is from the get-go, and project time constraints can often leave little room to plan. ProductPlan, a tech service provider, describes technical debt as a tool that allows developers to work forward, and return to an aspect later. Similar to a financial loan allowing investors to capitalize on a fleeting opportunity, technical debt can allow developers to make "rapid gains," (What Is Technical Debt? | Definition and Examples, n.d.) and release features on tight schedules with the intention of "paying back" the technical debt later. If correctly managed, it allows developers to avoid major delays, and get ahead on projects. With that said, technical debt can quickly cause issues in a project if mishandled, which is why it is critical to learn how to utilize it effectively.

Technical debt is a concept that is especially important to managers, as they are responsible for time allocations, and scheduling. But this leaves the question of how developers can manage technical debt, if they are not directly in control of the time spent on a project? This is where code health comes into the spotlight. We often consider whether code is good or bad based on its health. Healthy code is maintainable, secure, and can be easily automated (Saurav, 2022). Healthy code can be easily managed, which makes technical debt much easier to manage. If code is poorly written, it can make fixing previous shortcomings take longer than simply rewriting the code, which can make refactoring the code simply too time-intensive to be a viable option. Luckily, code that closely follows Object-Oriented principles, such as the tell-don't-ask rule, are much easier to maintain and test, which makes it all the more important that developers have a strong understanding of these principles.

Sources Cited

• Fowler, M. (2013, September 5). Tell Dont Ask. Martinfowler.com. https://martinfowler.com/bliki/TellDontAsk.html
• What Is Technical Debt? | Definition and Examples. (n.d.). productplan.com. Retrieved April 25, 2025 from https://www.productplan.com/glossary/technical-debt/
• Saurav, S. (2022, November 30). The four pillars of code health. leaddev.com. https://leaddev.com/software-quality/four-pillars-code-health

Interdisciplinary Approach to Software

Programming is often thought of as a sort of lone wolf skill that doesn't relate much to other topics or tasks outside of software development. However, this is simply not the case. While programming often lacks directly transferable skills, it teaches a uniquely logical and direct thought process that can be utilized to quickly pick up new skills.

This is partly due to the steep learning curve that programming has. When first learning to program, you're not necessarily learning how to actually program. What you learn in a beginning programming class often has near no relevance to what you'll be programming in the future, but it serves a much more important purpose. You are not learning to program, you are learning to learn.

A common sentiment that I believe encapsulates the initial few months of programming is that you are slamming you're head against a brick wall. The sheer amount of information is more than one can reasonably take in, and thus this sense of frustration is a common experience. However, what I've found is that in most cases, those who make it past this initial stage in the first few months often show significant growth following this barrier. Progress is extremely slow at first, only to skyrocket shortly after. Why is this?

In my opinion, the answer is Grit. The way that I, and many others I know, got past this initial barrier is by latching onto what little we did know, and focusing on just getting to the next step. This approach to learning forces you to stop getting caught up on the difficulty of a subject and instead break it apart piece by piece. As learners, we often try to get a complete picture as soon as possible, and it can be really tough to learn a complex skill or study a complex field without understanding everything. Programming forces you to instead focus on what you do know, and use your knowledge as a frame of reference, instead of needing to immediately understand everything all at once.

This learning strategy has assisted me significantly in the past, and I feel that many skills that I may have given up on once are now much more manageable knowing what I know now. Cybersecurity, a topic that I once had great difficulty with, became much more approachable once I used my experiences climbing programming's steep learning curve. Even outside tech, I have always suffered with music, and struggled to learn any instruments. However, with these experiences, I've been able to approach learning the viola, an instrument I had no exposure to, with much better results than I've ever had with my previous musical endeavors.

Capstone Project

I decided to do my capstone project in the form of a website, as I believe that this medium combines many of the different topics I studied in my classes, and highlights the interdisciplinary nature of my experiences. Some of the major subjects I took for this degree included programming, cyber-security, and user experience design. Through this website, I've created something that integrates all of these topics.

While I have room to grow in these areas, this website utilizes the skills I've accrued to form a final product. The design of the website is informed by the UX classes, as well as my early iterations and design prototypes that lead up to this version of the website. I decided to avoid using a website builder so that I could utilize my programming ability to build the site from scratch. I've built the site in relatively basic HTML and CSS, though I've set it up to use a virtual environment on the webserver to easily handle changes and environment updates. Finally, I capitalized on my experiences with cyber-security to create a SSL secured site, with a secure firewall to prevent any cyberattacks on the server.

Through these elements, I believe that I've been able to create a capstone website that demonstrates the different areas that I've studied in my schooling. It's been a somewhat cathartic experience, to be able to use everything I've learned, and I'm happy to report that I'm ready to move forward, with the new-found knowledge I've gained in tow.

Get in Touch