Home · Professional Self-Assessment · Code Review · Software Design and Engineering · Algorithms and Data Structures · Database

Professional Self-Assessment

My background began in the U.S. Air Force, where I served for over 6 years as an aircraft structures mechanic working hands-on with metals, composites, and coatings. This field required extreme precision, compliance with documentation, following specifications, and craftsmanship accountability. It built an internal system of discipline where one mistake could cause major consequences. If you cut corners, something broke, or worse. That mindset didn’t leave me when I changed careers and it followed me into every line of code I’ve written since.

Moving from physical to logical systems was not an easy transition. Physical systems give you feedback you can see and feel, but logic doesn’t always do that. I struggled to grasp software engineering principles and concepts from the beginning, leading me to feel discouraged in following this career path. I attended a full-stack software engineering immersive that allowed me to build my technical knowledge by working on simple, isolated code in early modules. I was focused on just getting things to work. That was enough for a while but as I progressed, I stopped creating code that just worked and shifted towards thinking about what I was building. Looking through my projects since I began coding shows my progression from using starter code on projects to creating my own.

During the immersive and class projects, each language I learned added something different to how I approach problems, even when it didn’t fully click. JavaScript introduced me to classes and modular thinking, and Python built on that foundation, eventually becoming the language behind the work in this portfolio. Assembly initially seemed difficult but it helped understand what stacks and registers are doing at runtime. Working with SQL and NoSQL gave me a better perspective of when each approach makes sense rather than just defaulting to one. C++ is still an area I am working to fully grasp, but the exposure made me think about memory and object lifecycles in ways I wouldn’t have otherwise.

Collaboration turned out to be one of the more valuable parts of the immersive program. Further into the program we began using Agile and Scrum methodologies with user stories, feature tracking, code reviews, and a shared codebase. While most of my academic coursework involved individual work, it made me realize the importance of documentation as my personal work could serve as a foundation for others to use. Similarly to the military, where inconsistencies could affect the final product, working within a team in software engineering taught me to be more intentional and descriptive in the code I wrote such as naming conventions, commit messages, and being careful of breaking changes. Working through code merges forced me to think about clarity and long-term maintainability when seen by others.

The final projects of the immersive added a client that required us to not only communicate clearly, but also turn their ideas into a web application. The requirements from the client were usually vague which meant we had to turn them into defined features, manage expectations and explain constraints and trade-offs. Additionally, we would meet with the client regularly to share progress and implement feedback to create an iterative process. After finishing the program, I stayed on as a Software Engineer in Residence for three months, mentoring students through the same process I’d just gone through. That experience was genuinely clarifying. Explaining something forces you to find the gaps in your own understanding pretty fast, and it pushed me to communicate technical ideas more clearly and adapt based on who I was talking to. Whether that was writing technical narratives, presenting code reviews, or adjusting explanations for students at different levels, communicating clearly about technical decisions became something I treated as part of the work itself. Both experiences reinforced that technical skill alone is not enough.

At first, I focused on any data structure that seemed the easiest to use instead of thinking about how data organization affects a program’s behavior. I relied on arrays, objects, or simple collections without considering scalability or efficiency. This was one of the first things I noticed during my capstone as the structure of the code started expanding. I didn’t think I would later find myself working on my own code and seeing how little thought and planning went into the data structure and logic. With more experience, I went back to the drawing board to reconstruct the game using the existing code. Once I separated the code into different classes, modules and data structures, it became easier to reason through the system. One of the major refactors involved the map modeling and navigation. I integrated a graph model for the map and added a method that builds and connects the rooms when the game starts. For the navigation logic, I added input parsing, rule evaluation, and defined win/loss checks. These two changes made the game easier to navigate and expand.

Backend systems and databases became one of my stronger areas starting in the immersive program and continued to develop throughout my coursework. Over time, I started separating routing, business logic, and data access to develop cleaner system boundaries. Designing schemas around relationships and constraints became more intentional, and I grew more comfortable writing complex queries that handle filtering, joining, and updating data. Instead of just creating RESTful APIs, I learned what the REST architecture represents and why those principles matter rather than simply following a pattern.

Security is something I had to be deliberate about building into my habits. While it was briefly introduced during the immersive, the coursework made me aware that it goes beyond the code I write, including external sources such as dependencies and libraries. I gained experience working with security guidance and concepts like using OWASP documentation, Defense-in-Depth, Least Privilege, and Security by Design. I have completed vulnerability analysis and reporting to check for security risks between my code and dependencies. I have also used password hashing and salting and implemented third-party authentication like OAuth to protect sensitive credentials. These experiences changed what I knew about security and helped me integrate it into my work early on.

The highlight of this portfolio is Vault 166, my Python text-based survival and exploration game built during my introduction to scripting course. It started as a single script using simple logic, dictionaries, conditionals, and basic input handling. I selected it for my capstone as it provided the perfect opportunity to not only expand, but improve a passion project. I created this game on my own with inspiration from the Fallout game and TV series using the course’s final project criteria as guidance. It was used as the foundation across all three capstone enhancement categories.

For the software design enhancement I started by breaking the single script into a modular, class-based system. This was done by moving small sections of code into their respective files and tested after each refactor to ensure the behavior of the game remained the same. I wanted to show how I approach taking an existing program and prepare it for future maintainability, clarity, and scalability.

In the data structures and algorithms category I refactored the existing logic by implementing a graph model for room navigation with nodes, edges, and rule-driven state evaluation. The refactor reduced the amount of scattered conditionals and made expanding the game easier. This was one category I felt I needed to be deliberate with as it would enable the use of the database and the accompanying logic.

Lastly, I added a lightweight database using SQLite and designed a schema to represent the states for the player, inventory, and rooms. The new structure and logic refactor made it possible to map objects to relational tables. Then I implemented save and load functionality using structured queries that allowed the game state to persist between sessions. These changes converted the game from a single script into a more structured application that can be expanded over time.

I’m still early in this career. But I’m not starting from scratch in terms of how I approach work. The accountability and attention to detail I developed before software didn’t go anywhere. I’m just applying it somewhere new, and getting better at it. My focus going forward is full-stack or backend development, but honestly I’m open to wherever I can contribute and keep growing.