Even after 3 years, a piece of advice I received in my foundational Engineering Science module remains etched in my mind. Then, as I struggled with using complicated formulas, the professor suggested that I trust my intuition and move forward with my best guess of the solution:
“Trust your intuition more than what the math tells you”.
As a freshman entering a field I believed was heavily mathematics-driven, the advice shocked me, forcing me to rethink my reliance on complex mathematics in engineering. Treating this advice as a ‘permission slip’ to ignore the practical realities dictated by formulas, I trusted the professor and allowed the advice to guide my engineering ethos. In this post, I reflect upon my decision to follow this advice. By interpolating other pieces of advice, I seek to better define intuition and understand its relation to action.
Looking back at projects I completed in my first two years, it is apparent that I often made decisions arbitrarily using ‘intuition’. Actions were driven neither by proper research nor scientifically grounded ideas. One such project was completed in ESP2110 (ESP Design Project). Typically done at the end of year 2, the module is designed to put a student’s independent research skills to the test. Despite having not much prior experience in electronics (the role I was assigned to), I did not take the time to go through the basics. Instead, I adopted a ‘complete by intuition’ mindset.
Fig. 1: Some excerpts taken from my ESP2110 logbook, a graded component where weekly progress updates were recorded (highlights are new and the highlighted phrases are typed out to increase readability)
In the weekly logbook (Fig. 1), I wrote that I did things by “trial and error”, highlighting the fact that actions were done without any prior research. The sheer number of times I used “not expected” and “unexpected” shocked me as I came across as completely unsure of what I was doing. Terms like “seems that” further exacerbated the impression that my decisions were cursory. When I attached diagrams of things going wrong, I only mentioned that I “met issues” instead of explaining my observations or hypothesising why things went wrong. Reading my logbook now, I struggle to find any theoretical underpinnings for my train of thought.
However, when I revisited a project I did at the start of year 3 for ESP3902 (Major Design Project I), I observed a marked improvement in my quality of work.
Fig. 2: (top) a simple diagram I made to plan the electronic design; (bottom) excerpts of my ESP3902 logbook with a colour-coded elaboration of each step
Instead of diving into the problem blindly, I analysed various electrical components, chose the most appropriate components, and created a simple-to-understand schematic (Fig. 2 top) that other teammates could refer to. I even chose to use images of the actual components to make the schematic as straightforward and illustrative as possible. Contrary to the confused student image portrayed previously, this logbook (Fig. 2 bottom) reflected the confidence I had in my methodology. I listed the problems I faced, identified possible causes, and suggested clear solutions. For some problems, I even listed alternative solutions after understanding the limitations of the components I was designing my initial solution with. The proactive research and thinking prevented the situation of ‘unexpected issues’ I faced so frequently previously in ESP2110.
As I reflected on why I experienced this improvement, the basic schematic I created reminded me of the internship experience I had over the summer between years 2 and 3. When I began the internship, I quickly realised that I was out of the ‘safe’ environment of a school lab where professors and lab technicians would step in promptly before something went wrong. In the workplace, supervisors trusted us to make the right decisions. I could no longer do things through ‘trial and error’ as expensive equipment might break, and injuries could happen. Before I even did anything, I discarded the ‘let intuition be the guide’ mindset and went around taking photos of parts, asking questions, and figuring out the basics of the equipment I was handling.
Fig. 3: An electrical schematic I made at the beginning of my internship to understand the workings of an electron beam gun
Rather than attempting to work solely with the complicated diagrams found in the workplace manual, I took the effort to draw the most basic schematic (Fig. 3). I described everything, avoided the use of complex electronic symbols (except the basic resistor and ammeter, components were represented with labelled boxes), and spent effort drawing neatly so that I could easily refer to the diagrams in a hurry. While the workplace manual diagrams and more advanced textbook illustrations seek to emphasise how each element improved the overall stability and reliability of the system, my ‘year-1-university-level’ schematics focused on why the system worked in the first place. The simplicity of my notes left no room for guesswork, enhancing my ability to work independently.
With my internship and ESP3902 project going well, I questioned the validity of the ‘trust your intuition’ advice. Moreover, in a hovercraft construction project, my professor stressed the importance of
“go[ing] back to first principles — if there is anything new, go back to the drawing board and build up the system using your mathematical foundation”.
This advice aligned itself well with the strategy I used in my internship and ESP3902. Since the two pieces of advice appeared to be at odds, I adopted the second strategy.
As I reflected on why a professor would give a piece of bad advice, I remembered another guidance I received in year 3 while taking a module about designing complicated analogue circuits:
“Even if the question looks complicated, don’t panic! You already know what’s going on”.
That professor stressed repeatedly that for any unfamiliar labyrinthine circuits, our theoretical foundation will aid us in intuiting the characteristics of the circuits. When I combined the three pieces of advice, the contradiction dissipated. Unlike my initial belief, ‘trusting one’s intuition’ did not mean throwing proper research away. Instead, intuition is a combination of experience, internalised knowledge, and logical deductions. In the internship, I fell back on my foundational technical training by using basic diagrams to understand the systems. In ESP3902, I used my experience to develop solutions and relied on internalised knowledge to anticipate problems. Looking back, perhaps what the professor meant to say is:
Trust your intuition! A strong foundation is sufficient to solve the most complex problems.
