The first time I completed the software engineering course I didn’t retain much. I had learned all of these concepts but didn’t really understand them enough to connect them to ideas outside of software engineering. I took the class to check an item off the undergraduate path list, and felt like the semester flew by. With the help of my research project, graduate school classes, and a summer internship, the concepts presented the second time around were more familiar to me.
The final project of this course was a good insight to the craziness that is Open Source Software Development. Issues such as a lack of documentation, lack of maintenance, or obvious limitations are common when dealing with open source software development. When it came to integrating the Solidity compiler with Meteor I spent a full day going down the rabbit hole. The end of that journey would leave me with a dead end. My fruitless struggle still hadn’t answered the question of “Is this even possible?”. With the help of one of a group member we discovered that it would be impossible to run the Solidity Compiler within Meteor. But the perilous journey wasn’t over yet! I then searched for a browser compatible version of Solc-js.This rabbit hole began with a GitHub page for an in browser version of solc-js named browser-solc. This project was created 6 years ago and following a trail of threads and GitHub links would lead me to the conclusion that this browser-solc was the predecessor to the remix-ide. They had turned their package into an application, and in the end it meant I could no longer integrate it. The perils of dead ends, rabbit holes, and fruitless endeavors are not unique to the software engineering world. If you’ve ever had a change of management or had a cornerstone staff member leave a job that you were a part of they sometimes don’t leave instructions. You’re essentially left to figure it out on your own, and sometimes you are now the one responsible for the task of the departed. You will have to research and try to fill in the blanks as you go along. Google searches and asking peers (even on a forum) can be helpful with informing you on what steps to take next. Don’t be afraid of hitting a dead end, because in the end it’s all the questions we asked along the way that can really be the most insightful.
In software engineering, the phrase Agile Project Management has become a buzzword. In fact, it can be somewhat of a meme in the software engineering space. You’re essentially tasked with taking a project in a certain direction, the key focus of agile is to have a quick turnaround time, and iteratively build upon the application so that way all the figurative boxes are checked off. Beyond that, there’s the concept of Issue Driven Project Management or IDPM which allows groups to come together and determine what needs to be done. The main thing I learned from IDPM is that “There’s always something to do”. This has been another way I have grown as an individual since first taking this class three years ago. Back then I would procrastinate on everything, but now you’ll rarely find me doing things last minute. In fact, I get anxious when an assignment’s due date is 48 hours away. I’ve learned that it’s better to get as much done in the beginning as possible, that way when you reach a road block such as a rabbit hole or dead end you’ll still have time to complete your task. Ever since I started studying for my GRE to get into the graduate program I’ve always found something to dedicate my time towards. Studying for the Security + certification, locking in financial aid through SFS, finding an internship to fill requirements, etc… The interesting thing I’ve found is that I’ve been more relaxed, and have been able to enjoy leisure time between deadlines. You’re able to honestly tell yourself “I’ve done all I can for the day, it’s time to relax”. Whereas, if you’re procrastinating you tell yourself “There’s always tomorrow.” But when tomorrow comes, and you end up stressing yourself out to an extent that just isn’t worth it. IDPM focuses on having 72-hour tasks which can be really helpful when tackling long term goals. Breaking down a big overwhelming issue into many manageable ones is very useful outside of software engineering. Creating deadlines for yourself and holding yourself accountable to them is also a key factor in IDPM and any other task you work on. Overall IDPM for a project is a great way to view goal-setting and time management skills, and just like all habits it does take practice getting used to it.
If I were to travel back in time to tell 2018 Hoku that he would take the software engineering class again, he would probably freak out. But what he doesn’t know is that he will learn new habits by going through process of getting into the MS ICS program at UH Mānoa and eventually going through the program itself. I was able to take this course again and actually put thought into what I was doing instead of trying to “check a box” to graduate. It’s a different experience being able to reflect on this past semester, along with the semester of four years ago. It’s such a different feeling being able to understand the in-class assignments and the homework. It was a simultaneously nerve wracking and awesome feeling to be the leader of the final project. But one of the best feelings is being able to appreciate the progress I’ve made as a bumbling lost undergraduate to a now less bumbling Master’s student who is about to graduate in four days.