Final Reflection
If you are given a choice between multiple design options to be a potential solution to a problem, what steps would you follow to make an informed decision about the best option? Can you provide an example of a time you employed these techniques?
When faced with multiple design options, I start by identifying the criteria that matter most to the end user and weighting them based on stakeholder priorities rather than my own preferences. I then score each option against those criteria, calculate weighted totals, and use the results to guide the decision while also checking that the math reflects the reasoning and not just producing a number to justify a predetermined choice. In the aircraft design project this semester, I used an Analytic Hierarchy Process decision matrix to choose between three mission profiles. Sensor capability was weighted at 38% and endurance at 28% based on what incident commanders actually need from a wildfire surveillance aircraft, and Profile A scored 8.72 versus 7.00 and 6.28 for the other options. I use a similar approach in my professional software work when evaluating technology stacks or architectural options, listing the requirements, weighting them by project constraints, and scoring candidates so the decision is defensible to stakeholders rather than a gut call.
What do you think are the most important things to consider when designing a brand new product?
The most important thing is understanding who the customer actually is and what problem they are genuinely trying to solve, not what they say they want. Customers describe symptoms and desired features, but the engineer's job is to uncover the underlying need and design to that. Beyond that, I think traceability matters enormously. Every design decision should connect back to a requirement, and every requirement should connect back to a stakeholder need, so that when something changes you know exactly what it affects. Feasibility under real constraints is equally critical because a design that works perfectly on paper but ignores manufacturing tolerances, cost limits, or operational environment realities has no value. Finally, verification has to be planned from the beginning and not added at the end. If you cannot describe how you will prove a requirement is met before you start designing, the requirement is not specific enough to be useful.
Tell me about a time when you had difficulties understanding a new concept. How did you handle the situation, and how did you overcome the obstacles?
The Arduino implementation in this course was the clearest example. I have extensive experience with web development and higher-level programming languages, but working with low-level hardware on an Arduino introduced constraints I was not used to. Specifically, the type system behaved differently than I expected, and the physical sensor hardware had characteristics that did not match the theoretical model. The map() function returns a long integer and not a float, which caused silent comparison failures that took significant debugging to identify. The TMP36 sensor in Tinkercad also did not reach the raw output value I assumed it would at maximum temperature, which meant my scaling was wrong and the threshold alerts never triggered even though the code logic was correct. I worked through it methodically by adding serial monitor logging to every decision point so I could see exactly what values the code was comparing, identified the discrepancy between expected and actual sensor output, and corrected the scaling range. The experience reinforced that hardware behavior has to be measured and not assumed, which is a principle I now apply to any system where I do not control all the inputs.
What is your greatest strength as an engineer, or future employee? Can you tell me a specific situation where this strength can be seen?
My greatest strength is systems thinking, which is the ability to hold multiple interconnected subsystems in mind simultaneously and recognize how a decision in one area creates consequences in another. This comes from my professional background building full-stack web platforms where a change to a database schema cascades through an API, a frontend component, and a client-facing feature all at once, and you have to trace those dependencies before making changes. In the aircraft design project this manifested when I selected Wing 3. I recognized that the lower chord length and thinner airfoil that gave Wing 3 its superior L/D ratio also created a tighter structural constraint for the spar, which required a taller I-beam to pass the stress check, which then consumed most of the available airfoil thickness. Catching that cascade before committing to the design prevented a situation where the aerodynamically optimal wing was structurally infeasible. That kind of multi-level dependency tracing is where I tend to add the most value on a team.
What "Systems Engineering" skills do you feel you have gained after this semester? Which of these skills do you feel will help you the most in obtaining an engineering career? ("Systems Engineering" is simply the multidisciplinary field of designing and managing complex systems; for instance, those with interrelated subsystems.)
This semester I developed skills in requirement definition and traceability, multi-criteria decision analysis using AHP, aerodynamic and structural simulation, UML behavioral modeling, hardware implementation and debugging, verification testing through formal FAT procedures, and financial analysis including present worth and ROI calculation. The skill I believe will help me most in an engineering career is formal requirement traceability, which is the practice of writing a specific verifiable requirement, designing explicitly to meet it, and then proving it is met through a documented test. Most engineering failures I have observed professionally come not from lack of technical skill but from ambiguous requirements that different people interpret differently. The ability to write a requirement tightly enough that a stranger could verify it without asking clarifying questions is rare and immediately valuable on any engineering team.
Explain several pitfalls you encountered during the design process where you had to change your project from your original idea. What were the trade-offs that came with changing your design?
The first pitfall was the LED wiring in the Arduino circuit. After carefully wiring the breadboard and double-checking connections, the LEDs still would not illuminate despite the serial monitor confirming the code was reaching the correct decision branches and outputting the right status messages. After adding a startup test that forced both LEDs on at boot, I discovered the LEDs had been inserted with reversed polarity, with the cathode connected to the Arduino pin and the anode to ground rather than the other way around. The trade-off was that catching this required adding diagnostic code that would not be in a production implementation, but it taught me that visual inspection alone is not sufficient verification for hardware connections.
A second pitfall was the wing selection process. Wing 2 initially appeared attractive because of its larger chord and higher lift coefficient, and its box spar fit inside the airfoil with comfortable clearance. When I ran the structural analysis and compared L/D ratios across all three designs, Wing 3's L/D of 32.99 versus Wing 2's 22.31 made clear that Wing 2 would significantly underperform on endurance, the second highest weighted criterion. The trade-off of selecting Wing 3 was accepting a structurally tighter spar fit with only 10mm clearance inside the airfoil, which would require tighter manufacturing tolerances in a real production aircraft.
A third pitfall was the mission profile selection. Profile C initially seemed appealing because its multi-role supply drop capability felt like it added more value per aircraft. Working through the decision matrix made clear that supply drop capability did not score well against any of the five criteria defined by the incident command stakeholder, because those criteria were centered on surveillance performance and not cargo delivery. The trade-off of selecting Profile A was accepting that the aircraft cannot serve supply drop or observer transport roles, meaning customers who need those capabilities alongside thermal mapping would require a separate platform.
Can you describe to me any unique projects or ideas that you personally created, and how you came up with those ideas?
Outside of this course I have built and am actively developing several systems that started from identifying a gap between what existing tools do and what I actually needed. One example is a self-hosted tactical operations platform I developed for emergency preparedness that integrates live map tracking, personnel management, communications planning, and an information aggregator into a single application that runs entirely on local hardware with no external dependencies. The idea came from finding that every existing tool in that space required either cloud dependency, expensive licensing, or significant technical overhead that would make it useless in degraded infrastructure conditions. Another example is a managed tabletop gaming platform I designed and built from scratch after identifying that existing services either charged players too much, paid game masters too little, or made session booking too complicated for casual players. I designed the business logic, payment flow, and platform architecture simultaneously rather than sequentially, which forced me to think about how each piece affected the others before writing a single line of code. I am also currently in the early stages of planning a custom VTOL drone project with a dual-processor flight architecture, a photogrammetry desktop application to compete with existing tools at a one-time purchase price, all of which started from identifying a specific frustration with what the market currently offers.
Outside of technical engineering, are there any soft skills that you feel you can contribute to a team? What are they, and can you provide some specific examples of where those soft skills were demonstrated?
Communication is probably my strongest soft skill, specifically the ability to translate between technical and non-technical audiences. In my professional work I regularly present complex technical decisions to clients and managers who do not have technical backgrounds, and I have learned to frame those decisions in terms of business impact rather than implementation detail. A second soft skill is autonomy under ambiguity. I am comfortable receiving an unclear or open-ended objective and producing a structured plan without needing every detail specified upfront, which came from years of freelance and independent work where the client rarely knows exactly what they want at the start of a project. A third skill is persistence through technical obstacles. The Arduino debugging process in this course is a small example, but professionally I have spent days tracing production issues through distributed systems without a clear starting point, and the ability to stay methodical and patient rather than guessing randomly is something many people find difficult. These three skills tend to be the ones my colleagues and clients comment on most.
Out of all the topics and projects, which activity do you feel you learned the most that will help you with your future success? Why?
The Factory Acceptance Testing procedures were the most practically valuable activity for my future work. Writing a test procedure forced me to define expected behavior precisely enough that someone unfamiliar with the system could verify it independently, and that discipline of precise specification is something I had been doing informally for years in software development without ever formalizing it. The moment of writing Step 5 in FAT-1 and realizing I could not describe what a lit LED looks like in Tinkercad without actually looking at one was a small but instructive example of how informal knowledge breaks down when you try to communicate it to someone else. Test-driven development in software follows exactly the same principle: write the test before the code, and if you cannot write the test, you do not understand the requirement yet. Having now experienced that process formally in an engineering context, I intend to apply it systematically to my technical projects going forward, particularly for complex systems where the cost of a missed requirement discovered late is high.
What areas of engineering or society do you find fascinating, that you could envision being a part of your future career? Why do these areas interest you? What do you hope to change or achieve in these areas?
I am drawn to several intersecting areas that all share a common thread of building systems that work reliably under real-world constraints rather than ideal conditions. Autonomous and drone systems fascinate me because the engineering challenge is not just making an aircraft capable but making it verifiable and trustworthy enough to deploy in high-stakes environments, which is a much harder problem. I am actively working on a custom VTOL drone project with a dual-processor architecture pairing a flight controller for real-time motor control with a dedicated compute module for autonomy and camera processing, and the systems integration challenge across those two processors is exactly the kind of problem I find genuinely engaging. Electrical engineering and embedded systems are a growing interest as well. Building guitar pedal circuits introduced me to analog circuit design, and the Arduino project this semester connected that hands-on hardware interest to software, which opened up a much larger space of projects I want to explore including custom sensor hardware and low-power embedded communications nodes for field deployment. The automotive and vehicle engineering space also interests me from a systems perspective, particularly the shift toward software-defined vehicles where the boundary between mechanical engineering and software engineering is dissolving in ways that create interesting design opportunities. Across all of these areas what I hope to contribute is a design philosophy that treats degraded operation and real-world variability as first-class requirements from the start, building systems where reliability under stress is designed in rather than hoped for, because I think that gap between laboratory performance and field performance is where most engineering value is currently being left on the table.