This semester, I took my very first ICS course–ICS 314. Now you may be wondering how I’m starting in the 300 levels when it’s my very first ICS course, and I’ll tell you, I’m no genius that skips courses. The truth is I’m actually a computer engineering major, and up until this point all of my coding classes have been Electrical Engineering classes which mostly only cover languages like C, C++, and very little Linux (just enough to be able to navigate through your files). This is the very first class that I’ve ever had to learn Javascript, HTML, or any kind of web development, and while I feel much more confident in those skills after this semester, the real prize I’ve gained from this semester is personal growth. Throughout this semester, I’ve gained more confidence in my abilities to learn new skills, learned new strategies to combat procrastination, and gained knowledge of how to better cooperate with teammates.
Let’s start from the beginning of the semester. I mentioned before that I had never dabbled in the skills needed to pass this course, so as you could imagine, coming into this semester I was more than a little scared. I had known students who took this very class and struggled and stressed over it–and those were people who I considered to be smart! Going into ICS 314, I had no confidence I could do it, and I’m not very social in classes so I have very few friends who I could even turn to for help in programming. Things were looking bad.
Why would I even bother taking this class? Because I need it to graduate, of course!
So I bit the bullet and jumped into it, planning to just give what I had and hope for the best. This class had the most brutal way of teaching I had ever been exposed to, and that was “Athletic Software Engineering.” To sum it up, it’s basically coding under pressure. Every week, we would have one practice Work Out of the Day (WOD), and one real WOD. If you got your program working within the allotted time, you passed with full points! But if your program didn’t work, then you got zero points. These WODs could murder your grades, but they could also save them, and that’s exactly what happened to me.
I failed the first couple of WODs. I didn’t really understand Javascript syntax at the time, and I kept making silly errors where I would be so close–but not quite. It was frustrating, and with 0/200 points for the WODs I was really debating on dropping the class. But the professor said not to worry about it at that point of the semester, and that everyone still had a chance of getting an A. So I stuck to it, and what do you know, I got better, and we started getting into new and exciting things, like User Interface Frameworks.
Let me tell you (if you’ve read one of my past essays, you may already know), the last time I did any kind of web development was with HTML on MySpace, and it was just enough for me to be able to customize my page. I thought I would absolutely dread web development, but with the introduction of User Interface Frameworks, we could make more than the basic, prehistoric looking web pages of the past–and it was pretty easy and intuitive too! Thanks to the existence of UI Frameworks like Semantic UI and React, anyone just starting out can practice recreating web pages with simple, natural language based syntax. A lot of the commands and names can even be guessed, but if you can’t think of the name on the spot, Semantic UI React has amazing documents to refer to. Don’t know what icons are available to you? Just Google Semantic UI React icons and a whole list will pop up! It’s amazing, really–so much so that I believe out of all the WODs that had to do with web design, I only didn’t pass one (and that’s just because I couldn’t get a text line to change colors)! That’s shocking for a girl who had a 100% fail rate at the beginning of the semester! Thanks, Semantic UI React!
The next skill I gleaned from this course is much more straight-forward, and though in my case it applies to software engineering, I feel like this skill can be used throughout many aspects in one’s life. This skill is a type of Agile Project Management called Issue Driven Project Management, and while that may sound extremely technical and complicated, it’s actually exactly what it says it is. Managing your project based on the issues it presents. That’s not to say your project has issues, but that the project has tasks that need to be completed, and these tasks are referred to as issues.
Throughout my entire life, people have tried to give me advice on how to procrastinate less. Reward yourself, do a little each day, just do it, etc. If you’re as terrible a procrastinator as any other human, you’ve heard it all too. It turns out, diamonds are made under pressure, and only if you feel that pressure you’ll start to do something. That’s how Issue Driven Project Management works! You break down your total project and assign yourself manageable tasks that need to be completed by a certain time. The final project in ICS 314 put us into groups and forced us to use Issue Driven Project Management, but it turned out to be one of the best pieces of procrastination advice I have ever received.
How we applied Issue Driven Project Management was through milestones and assigned issues. We were given 3 milestone due dates, each one spaced one week apart. By milestone 1, we needed to have at least two tasks (or issues) accomplished per team member. So we all assigned ourselves tasks at the beginning of the week, and by the due date of milestone 1 we had all finished our tasks. Then, we moved on to milestone 2 and started the process again. Repeat the same process for milestone 3. Each time I would procrastinate until I knew I couldn’t anymore, but with those milestones in place we were getting tasks done by the time they needed to be done. Can you imagine if they hadn’t been organized into milestones and issues? I definitely would have ended up procrastinating the full 3 weeks and then struggling way more than I did.
The last important, personal growth skill I gained from this semester was teamwork. As I mentioned earlier, for the final project of ICS 314 we had to work in groups. I am normally terrible at team communication, but one thing really helped take that out of the equation, and that was coding standards. In my early days of coding classes, I never understood coding standards. If it worked, it worked. But as I’ve been put into team situations more and more, I’ve realized the worth in coding the same way. That way everyone’s code is easier to read, cleaner, and goes together much more seamlessly. This semester I was introduced to a coding standard called ESLint with IntelliJ. If you’re like I was before this semester and have no idea of what ESLint is, it is a coding standard that you can put into your IDE (Integrated Development Environment). It will automatically tell you anytime your code is not conforming with the ESLint standard by underlining the part in question in red, and offer you solutions to fix it! Gone are the days of mismatched bracket placements and spacing. Not once did I have to explain what my part of the code did other than the main function of it. Thanks to coding standards and amazing teammates, this group project went off without a hitch! Even outside of coding, having something standardized seems extremely helpful in any group situation!