Analyst & Engineer

Overview

The Analyst & Engineer Portfolio is an experience-first professional platform designed to show how I approach problems from both a human and technical perspective. My background in customer-facing healthcare support gave me firsthand exposure to complex workflows, system dependencies, communication gaps, operational constraints, and the impact that technology has on the people using it. Instead of separating those experiences from my technical growth, this portfolio connects them.

The work demonstrates a progression from solving individual customer problems toward understanding patterns, documenting requirements, analyzing workflows, identifying opportunities for improvement, and building technical solutions.

The goal is not simply to say that I am interested in analysis and engineering. The goal is to demonstrate how I think.

The Vision

I approach technology from the perspective of both the person using the system and the person trying to understand how the system works.

That perspective creates a natural connection between business analysis , data analysis , quality analysis , process improvement , and software engineering .

A customer reports a problem. An advocate investigates it. An analyst identifies the workflow behind it. A quality professional asks why the problem occurred. An engineer considers how the system could prevent or solve it.

I want my work to operate across that entire chain.

The portfolio therefore focuses on the intersection between people, processes, data, systems, and technology.

How I Think as an Analyst

Analysis begins with understanding the problem before attempting to solve it. I focus on separating symptoms from root causes, identifying stakeholders, understanding workflows, documenting requirements, and using evidence to guide decisions.

• Problem definition — Clarify what is actually happening before jumping to a solution.
• Root-cause thinking — Look beyond the immediate issue to understand why it occurred.
• Requirements thinking — Translate user needs and business problems into clear, testable requirements.
• Workflow analysis — Understand how information, people, systems, and decisions move through a process.
• Data-informed decisions — Use measurable evidence to identify patterns and evaluate possible improvements.
• Stakeholder awareness — Consider the needs of customers, employees, business teams, technical teams, and other stakeholders.
• Documentation — Turn complex information into clear documentation that others can understand and use.

How I Think as an Engineer

Engineering gives analysis a place to become tangible. Instead of stopping at identifying a problem, engineering asks what can actually be built, tested, maintained, improved, and scaled.

My approach emphasizes understanding the problem first and then choosing the appropriate technical solution.

• Build with purpose — Create technology to solve a defined problem rather than adding complexity for its own sake.
• User-centered development — Consider how real people will interact with the system.
• Maintainable code — Favor clarity, organization, consistency, and documentation.
• Testing and validation — Verify that functionality behaves as expected and remains reliable as systems evolve.
• Debugging — Investigate unexpected behavior systematically rather than relying on guesswork.
• Iterative improvement — Treat development as a process of learning, testing, measuring, and refining.

Systems Thinking

One of the most important connections between my professional experience and technical development is systems thinking.

In customer-facing environments, a problem rarely exists in isolation. A customer issue can involve a person, a workflow, a database, a business rule, an external system, a communication channel, and a handoff between teams.

Solving the immediate problem matters. Understanding the system that created the problem matters even more.

This perspective influences how I approach technical projects. I look at the complete flow:

• Input — What information enters the system?
• Process — What happens to that information?
• Decision — What rules or conditions determine what happens next?
• Output — What does the user or business ultimately receive?
• Feedback — How do we know whether the result was successful?

This allows me to move from simply fixing symptoms toward understanding architecture, workflows, dependencies, and opportunities for improvement.

Development

The portfolio itself was developed as a working example of the principles it communicates. Rather than functioning as a static résumé, the site is an interactive web application designed around accessibility, responsive behavior, reusable components, structured content, visual hierarchy, and maintainable front-end architecture.

The development process includes consideration of:

• Semantic HTML
• Responsive CSS
• JavaScript interactions
• Theme switching
• Navigation architecture
• Accessibility
• Responsive layouts
• Component-style content organization
• Performance-conscious asset usage
• Progressive enhancement
• Maintainable file structure

The site is therefore both the portfolio and one of the artifacts demonstrating the technical skills described within it.

My Analysis Workflow

When approaching an unfamiliar problem, I use a structured process rather than immediately jumping into implementation.

1. Understand — What is the actual problem?
2. Observe — Who experiences the problem and under what conditions?
3. Investigate — What systems, data, rules, and workflows are involved?
4. Define — What are the requirements and desired outcomes?
5. Analyze — What patterns, dependencies, risks, and constraints exist?
6. Design — What solution best addresses the underlying problem?
7. Build — Implement the solution with maintainability in mind.
8. Validate — Test whether the solution actually solves the intended problem.
9. Improve — Use feedback and evidence to refine the result.

Quality Analysis

Quality is not simply the final testing step. It begins when the problem is defined and continues through requirements, design, development, testing, deployment, and user feedback.

• Requirements quality — Are requirements clear, complete, consistent, and testable?
• Functional quality — Does the system behave as intended?
• User experience quality — Can users understand and successfully interact with it?
• Data quality — Is information accurate, consistent, and meaningful?
• Process quality — Does the workflow produce reliable outcomes?
• Technical quality — Is the implementation maintainable, understandable, and resilient?

This mindset allows me to approach quality as a continuous responsibility rather than something that happens only after development is complete.

Core Capabilities

• Business Analysis — Problem definition, stakeholder thinking, requirements, process analysis, documentation, and solution evaluation.
• Data Analysis — Investigating information, identifying patterns, organizing findings, and using evidence to support decisions.
• Quality Analysis — Testing assumptions, validating requirements, identifying defects, documenting issues, and improving reliability.
• Process Improvement — Identifying inefficiencies, recurring problems, unnecessary complexity, and opportunities for better workflows.
• Systems Thinking — Connecting users, business rules, workflows, data, applications, and technical dependencies.
• Software Engineering — Building responsive, functional, maintainable software while continuing to strengthen technical depth.
• Technical Communication — Explaining technical concepts clearly to both technical and non-technical audiences.
• Customer-Centered Design — Keeping the real-world user experience connected to technical and business decisions.

What I Learned

My technical development has changed the way I look at problems. I no longer see a difficult interaction, inefficient process, confusing interface, or recurring issue as an isolated event. I naturally start asking what exists underneath it.

What information is being passed? Where does it go? Which system controls the decision? What assumptions are being made? Where can the process fail? What does the user actually need?

Those questions are what connect my experience as a customer-facing professional with my development as an analyst and engineer.

Customer experience taught me to pay attention to people. Analysis taught me to investigate the problem. Engineering is teaching me to build the solution.

The strongest work happens when all three perspectives are considered together.

What This Portfolio Demonstrates

Why This Portfolio Matters

This portfolio represents more than a transition into technology. It represents the evolution of how I solve problems.

My professional experience taught me that technology is never completely separate from people. A system can technically function and still create a frustrating experience. A process can be documented and still be inefficient. A feature can be delivered and still fail to solve the original problem.

That is why I want to approach technology from both sides. I want to understand what the business needs, what the user experiences, what the data shows, and what the technology can do.

My long-term goal is to continue developing across analysis, quality, systems, and software engineering so I can contribute to solutions that are not only functional, but meaningful.

Understand the person. Analyze the problem. Understand the system. Build the solution. Improve what comes next.