3 Life Lessons, Courtesy of 3 Design Exercises

After nearly two weeks of constantly being inhabited, last Thursday evening saw peace and quiet finally return to the Electronics Lab primarily used by the first year Electrical and Electronic Engineering (EEE) students. All monitors were dimmed, the desk surfaces were clean and visible, and the absence of any students was stark; it was the familiar scene belonging to the aftermath of a design exercise. Familiar because it was the same scene to grace the lab at the end of the first semester, after two weeks of not one, but two back-to-back design exercises. Compared to those two weeks, these past two haven’t been all that bad. But this post won’t detail all the goings-on of the design exercises in EEE Part I; doing so would ruin the entirety of the experience for future students and frankly, the post would end up with the length of a thesis if I did. Rather, this not-so-serious post aims to impart three important life lessons I have learnt from my experience with design exercises, along with the somewhat comical ways I came to learn them.

But first, what exactly are design exercises? To friends and family, I have always liked to describe them as extended versions of the regular laboratory work we do as EEE students; the difference being that unlike our regular laboratory work, design exercises span multiple days rather than a three-hour session, befitting of the higher level of complexity and amount of time and effort we are required to invest. Naturally, design exercises correspond to a larger percentage of our final grades than the ordinary laboratory sessions, thus raising the stakes and as might be expected, our stress levels as well. Now that the context has been established, onto the lessons!

I can safely say that this was the first lesson I learnt, because I learnt it as the second day of my first design exercise came to an end. For that specific design exercise, we were given tasks to complete for each day, and at the end of the day, the lecturers would mark us on our progress accordingly. On that fateful day, when a lecturer approached our bench to mark my lab partner and I, we were confident in our work thus far and proceeded to run our simulation. However, we were flustered to see that the results were not as we expected; they differed from the results we had got when we had run the simulation only five, ten minutes earlier. Fortunately, we were able to quickly pinpoint the code modification that resulted in the error, and fixed it to give a correct demonstration – but words cannot describe the panic we felt in that moment where our code was not behaving as we expected. Needless to say, “It was working a minute ago!” unfailingly becomes a catchphrase during design exercises, and – for the most part – we no longer feel panicked, because we inherently expect for our codes to misbehave now and then – especially when it matters the most. So no matter how much you prepare yourself for every scenario you can possibly think of, don’t be surprised if a scenario you didn’t think of tries to take you by surprise; as the famous saying goes, “Hope for the best, and be prepared for the worst.” (Bonus lesson: always save working versions of code before making modifications; the slightest change could break your code if you aren’t careful!)

For anyone who has spent a considerable amount of time programming, they would probably concur that “programming time” mainly consists of debugging code (i.e. finding and removing errors) rather than writing code. All three of our design exercises involved programming to a major extent, and hence a large proportion of our time in the lab was spent painstakingly examining our codes, line-by-line, to figure out the problem. Probably the most important lesson I have learnt from constant debugging is that when your code is behaving unexpectedly, you (as the writer of the code) have made an incorrect assumption somewhere along the line, or even multiple. These assumptions are usually made subconsciously, and thus an important part of debugging is quickly identifying the hidden assumptions you have made, and questioning whether the assumption is correct. Having done this enough times to create a mental list of assumptions to question, I always begin with the most straightforward, yet still dangerous, assumption, “There are no typos in my code.” It can be very frustrating to comb through and painstakingly edit your most complicated lines of code in hopes of solving the problem, only to find that it had been a stray bracket or missing punctuation all along. When things go wrong, it is only natural to suspect the areas that we are least confident in to be the cause, but it is worth double-checking the assumptions you are confident in first, just to be sure!

Taken literally, it sounds counter-intuitive, but I can recall many instances where my lab partner and I found ourselves stuck due to one problem or another, and unable to make any progress because of it – for hours on end, we would brainstorm possible solutions and attempt to overcome the obstacle in vain – but somehow, after taking some time away from the problem and leaving our thoughts to be occupied with anything else, we would come back and be able to solve the problem in a fraction of the time we had spent before giving it a break. It goes without saying that, by walking away from a perplexing problem, it won’t just magically become one that can be solved with ease once you return to it (oh, if only); the point is that, like unresponsive computers, our minds also need a reset after hours of hard work. Taking a deserved break helps momentarily clear your mind, which in turn aids in filtering out the unimportant thoughts that tend to clutter our minds when we overexert ourselves. Adhering to this principle probably sounds easy enough, but from personal experience, I’ve realised that the more time we spend stuck on a problem, the harder it becomes to step away; we know that we are able to overcome it, and therefore refuse to give up – it is thus worth reminding yourself, at that point, that although it may feel like you’re giving up, taking a break is not a sign of defeat, rather it is an essential step towards the end goal.

The last lesson actually explains why I’ve spent the past few hours writing this post, instead of studying for my final exams that start next week; now that I’ve spent quite enough time deviating from my revision schedule, I think I’m all set for a productive session of revision – one that includes quick breaks every few hours, of course. For those of you who are also in the midst of exam season, I hope this post was so beneficial, or at the very least somewhat entertaining, that you don’t regret interrupting your studying, and I wish you all the best with your exams!