Find out why this musician-turned-engineer chose to embrace her creative side and go down the rabbit hole of Software Engineering.
Establishing a Level of Complexity
“…a technique for managing complexity of computer systems…by establishing a level of complexity on which a person interacts with the system, suppressing the more complex details…” Abstraction (Computer Science), Wikipedia, the free encyclopaedia, April 2016
Abstractions have followed me since early this semester, which is why I’ve decided to liken my Software Engineering experience to one. Like any good abstraction, it provides you with a hopefully easy-to-use interface, hiding all the nitty-gritty of software life (i.e. the contents of the COMPSYS 201 assignment I need to finish) which could only serve to steer you away from something you might one day come to love.
My software journey started on the 30th of November. I had just arrived in Whitianga with a few friends, ready to enjoy the not-quite-summer weather. I checked Facebook to find a message saying that a friend was switching his first choice specialisation from Software to EngSci. This guy was about the software-iest guy I knew. If he didn’t think he’d enjoy software, what chance did I have? At that point, I also straddled the EngSci/Software fence. I’d previously told myself it was my best option because
- I enjoyed 131
- It had no mechanics
- It had no Part III maths paper
- I had a feeling I’d enjoy it since year 12 despite my previously failures at learning C, and my Neopets-limited experience with HTML and CSS
Every mention of specialisations only made me doubt my choice more, but for some reason, I couldn’t make myself switch. The 30th of November was the day I really decided to do software: for myself, and not for the benefits of having that friend who already knows everything.
By the time the semester started, I’d read mocking of people who chose software because “131 was fun”, and been berated in class forums to learn Java ASAP. Some advice: liking 131 is a perfectly valid reason to be interested in software, and don’t be disheartened by any difficulty learning Java before the semester. In fact, if you have anything at all better to do, don’t learn Java.
Unfortunately, I didn’t have my own advice, and wasn’t in any state to listen to the more moderate advice and opinions being dished out. I went into the semester feeling inadequate and already behind. I thought I couldn’t possibly enjoy this. I was very wrong.
The classes have been great. SOFTENG 251 is assignments (which teach you something), non-compulsory labs (which try to teach you something), and open book tests (which teach you something different) about objects taking to each other. COMPSYS 201 has been a struggle, but there’s nothing like Boolean algebra, sequential circuits, and finite state machines (read: very logical flow charts) to wake you up in the afternoon. I don’t do ENGSCI 213, but you can probably read what someone else has to say about 211, and think of 213 as “less content, but more depth”. My favourite has to be SOFTENG 250. There’s something about looking at pseudocode to determine runtime complexity, sigma notation, and salami being sorted (or something like that) that brings me joy. Assignments mean being overwhelmed is a possibility, but so is feeling the satisfaction when you run code successfully after 4 hours debugging.
Software is a challenge, and this abstraction can’t go into much detail about that. However, I also can’t communicate how interesting all the concepts are, and what it’s like to have the coolest cohort around.
-Aimee
I didn’t realise we needed titles (or, Don’t Mind Me — I think everything is fun)
A semester is done, and so am I! It’s been a month since my exams finished and the new semester has just started, but I’m still feeling the relief of those exams being over.
COMPSYS 201 – Fundamentals of Computer Engineering
If I had to pick (which I don’t, but I did anyway), I’d say that 201 was my least favourite course last semester. That is not to say I did not appreciate it. It comes in at least favourite because it was simply my favourite at no point during the semester. In fact, post exam results I may even call it my favourite, as it was somehow the source of my highest grade. My interest in the content fluctuated greatly during lectures, but when it came down to sitting and actually working through everything during study break, it ended up being alright, perhaps even fun (although I am taken back to the Queen parody I wrote in an attempt to learn all about embedded C, so I will take that back).
The course covers a lot, and is taught in three sections. The first is pretty much ELECTENG 101’s sections with the flip-flops (but not the flip-flops bit—mostly the Boolean algebra), plus fancy flowcharts (finite state machines), with that one lecture on Moore’s Law thrown in for good measure. The second section is the flip-flop part of ELECTENG 101, but with a lot more flip-flops put together to make various datapath components that prove to be far more useful than any one flip-flop. The final part is something I found entirely different: embedded C programming. While I’m told it relates to the previous content of the course, I could never quite make the connection. It focused on a particular microcontroller, and how to use its on chip resources to do things like make lights flash at specified rates.
SOFTENG 250 – Introduction to Data Structures and Algorithms
In my first blog post, I mentioned how this course won my heart. Unfortunately, non-250 assignments made this a difficult one for me to keep up with towards the end. I found myself swallowed up by all the graph theory. The ideas interested me, but I started feeling gaping holes in my knowledge, which only put me further behind. In the end, it was the multichoice exam which spelt the demise of my grade (following a respectable percentage for coursework).
The course introduces Big-O notation, and time complexities of a variety of data structures and algorithms. As an appreciator-but-not-doer of maths, I found all the analysing algorithms on data structures to see how (fast) they execute fun. There’s not much else to say about the content without this becoming a list, but I’d like to thank heapsort for being my favourite sorting algorithm this semester.
SOFTENG 251 – Object Orientated Software Construction
My ability to understand 251 content rapidly plummeted in the week or so before mid-semester break, greatly affecting my enjoyment of the course. I began to really resent the whole thing— there were so many concepts to get my head around, and I wasn’t finding ways to apply them to consolidate my learning. This ended up being my worst course this semester in terms of a final grade, but became my favourite in the last six weeks, and has me convinced that it’s the most useful course this year has to offer (possibly due to some words from our lecturer Ian Warren).
The first half was an introduction to object oriented design principles in Java. There was a lot of learning about classes and objects (who would’ve guessed), and it’s a giant blur now. Take that blur as a positive – there was enough opportunity to apply the concepts we learnt about so that we could understand concepts as a whole instead of stressing smaller details. It also helped that we could bring a journal (which I have been informed refers to any number of bound books with handwritten notes) into assessments.
The second half used the first half to show us how more complicated aspects of Java (i.e. various frameworks) work, and how to make our lives easier with tried and tested design patterns. We also got linked this great JavaWorld article to read about them (they can be explained pretty well in the 9th paragraph). Not only was it examinable, but it was also rather useful. The three-part assignment we did was great for the whole learning thing, and I found it fun because I have a strange take on the concept of “fun”.
-Aimee
A Little wget Magic
SOFTENG 206 – Software Engineering Design 1
This is the course where you get to try out everything you’ve learnt in the year and see if it actually works (or more accurately, if you actually understood it and have some idea of how to apply it). Our project is to build a Spelling Aid application called voxSpell. We’ve had assignments working on aspects of the final project, with that project due at the end of the semester. The application name prompted me to make the whole application wizard themed to exercise my design muscles. There are some prizes (valued up to $100) for the best projects. After looking at what people have produced for assignment 3, I don’t think my animated wizards are going to cut it.
The project takes up most of the second half of the semester. The first half was preliminary and working with Linux operating systems. That in turn was mostly about Bash commands and scripting, which allow much more powerful control over what we can do with a computer. As pointed out by our lecturer Nasser with the help of Jesse Eisenberg, hackers don’t use a mouse (except when blogging). I haven’t done much (read: any) hacking, but I’ve found the skills very useful in situations where I forget how Google works.
SOFTENG 211 – Software Engineering Theory
The content is interesting once you get your head around it. It feels like a totally new language (and not in the learning a new programming language way). You start off with Boolean algebra, which is all good, but then you move into first order logic, which ended up being good, but confused me for a couple of weeks. Seeing this thing everywhere is a bit intimidating. We’ve just wrapped up set theory, which went well for me. Now we’re learning about graphs. Again. Expect a lot of graphs in second year.
The big thing to remember is that the team running the course are there to help you. It also doesn’t hurt to ask your peers- not just the ones in software. It turned out all my Engsci friends did a compsci elective with the same content last semester. That would have been great to know a half-semester ago.
This course is known for having notoriously difficult assignments. We’ve only handed in one (of two) so far, but I may have been brought to tears at some point in my thirty-or-so hours of assignment-doing. I conducted a class survey (which I can hopefully make a post about later), and someone wrote a very uplifting additional comment about how software is about keeping on going, even when the degree takes you down. That’s it. That’s software experience.
SOFTENG 254 – Quality Assurance
Quality assurance is absolutely fascinating. I was not looking forward to the course, as the “software-iest guy I know” from my first post seemed incredibly put off by it. As it turns out, I find it pretty interesting. It’s all about how to test software, how to write software so you don’t mess up so much, and generally, well, developing better software. I’ve found the coursework and content very reasonable, and the concepts rather intuitive.
At that same time, I’ve become convinced of how difficult it is to make sure any software is good. I question what good even means. Is it having no faults in your code? How can you know there are no faults in your code? I mean, you don’t know how much is wrong until you find what’s wrong with it, and when you find that, you can fix it, and it’s not a fault anymore—right?
-Aimee
Software: Better with chips, but still pretty good (which is meant to be a Douglas Adams reference)
As the end of the semester draws closer, my workload only becomes more intense. I’ve got a 40% assignment due tomorrow (fortunately handed in), another assignment due on Sunday, and a beta version of a final project due on Tuesday (plus the final version and report due in three weeks). There are two tests to go, and another assignment we haven’t yet received. Oh, yes—there’s an essay as well! Engineering is not the escape from essay-writing we thought it would be. Fortunately, I premade some content for this post as to not be stuck in my proof-reading loop for an indefinite amount of time.
I was warned about the massive workload associated with post-week eight-time of this semester. I was warned that if I found anything in this degree difficult before, I was going to have a really bad time in these weeks. Sleep was to become a luxury, along with free time, and I have received confused looks for my shred of will that keeps me aiming for good marks. I didn’t believe any of that until a couple of days ago, already halfway through week 10. In fact, last week, I seemed incredibly ahead of schedule.
While I don’t expect to have no sleep, I am in constant fear that I’ll forget to do something (e.g. write a presentation, or study for a test). You’ve heard it all before- time management is key. While everything is very intense right now, I’m finding that I enjoy all of the (software-related) work we’re doing. I’m proving that I get far too into assignments, especially the big, design-y ones, and that I really like drawing GUIs. In the last week, I think I have spent around 20 hours on my final project for my design paper with everything else that’s due. The lecturers of that course warned not to spend too much time on the project, when time could be better-spent improving your performance in other courses. I’ll find out if I should’ve listened in a couple of weeks.
I’m very grateful that me-from-two-weeks-ago had the foresight to, as usual, start every assignment the second the PDF is released. While the strategy can prove annoying, as it forces you to be a person who finds the pitfalls in the assignment instead of the one who is warned against them, I can’t have it any other way. I like to think I learn more, and ultimately end up less stressed close to due dates.
That’s enough of “How Aimee Handles the Workload”—I made a vlog back in the good ol’ days, when the hardest thing I had to do was remember how C worked. This was around the same time (as now) in Semester 1. Hopefully that gives you some insight into what typical software life is like. As a person who rewrites instead of proofreading, I’m refraining from watching it.
This has been a fantastic year, and I take nothing back about having the coolest cohort around. Some assignments have been utterly morale-draining, and some exams potentially degree-ending. However, those assignments have also been rewarding to finish, the incomparable wave of relief and tears of both pain and joy an experience unique to an engineering degree. The exams have taught me to fight harder and work smarter, and to keep working through everything. Defeat should be only a last resort.
To you first years, with your five drop down boxes of nine options each— there are over 10,000 selections you could make, if my calculations are correct (it’s been a while since Scholarship Stats, so they probably aren’t). If you feel software is your top pick for specialisation, don’t be afraid to go for it. There are people who will say the GPA for entry is too high, and it’s “smarter” to put something else down as your first choice. I say just do it. Even if you don’t get in first time around, there are other pathways for entry. If you do get in and realise it isn’t for you, there are ways to get out. The stuff you learn (namely how computers work/are made up, and how information is stored) in first semester will be relevant in whatever field you go into because of the society we live in. Concrete are the paths, not your future.
Best of luck to you all. It’s been a pleasure being your software editorial writer, and I hope something in this has been helpful.
Thanks,
– Aimee
ABOUT AIMEE
My name is Aimee. I’m your possibly-less-than-typical-in-software artsy type who sings everything, draws people as cats, and comes up with terrible puns. You can find me in and around the Engineering Cafe playing cards, eating, and/or talking too loudly.
In high school, I had a lot of doubts about engineering. I mean, I’ve been telling people “I want to do engineering” since everyone with any interest in science claimed they wanted to be a vet (i.e. Year 7), but in Year 13, I realised some important things:
1. I only liked maths because I thought I was good at it
I did MATHS 153 that year, and had to actually study to do well in something maths-y for the first time. In hindsight, that probably just pushed pure maths off the table for me.
2. I didn’t actually like physics
I’d just gone along with the expectation since I kept telling everyone “engineering, yeah!”.
3. I really, really like music
A lot of my school life was music, and despite years of complaining about performance, I was enjoying it more than maths and physics.
(Un)fortunately, the careers advisor looked at my subjects and academic record, and simply reassured me that I would succeed in engineering. I don’t know about succeeding, but I’m definitely enjoying it.
So, what’s kept me here? Was it my hope of contributing positively to society? Or the food? Or the fun? Regardless, I can’t imagine being anywhere else, and I hope that’s not due to any lack of imagination.