There's Always More to Learn in Software Engineering
08 May 2023
Agile Project Management: Like second nature
Before taking ICS 314, I had already known a decent amount of things about software engineering. Having worked in a web development job, one concept I already had experience in was Agile Project Management, or more specifically, Issue Driven Project Management. In such type of project management, a board is organized into columns for to-do, in-progress, and completed. In every column, there were issues that contained information on how to complete the said issue. Issues are created and placed into the to-do column. When someone picks up the issue, it gets moved into the in-progress column. And finally, when the issue is complete, it is moved into the completed column. I really enjoy Issue Driven Project Management and it felt like second nature to me since I had used this type of project management on my job. One of the benefits of Issue Driven Project Management is when you are struggling to complete an issue, you can just move the issue back into the to-do column and have someone else take a stab at it. However, one problem that may happen with Issue Driven Project Management is that you could run out of issues in the to-do column, stopping productivity in the team for a moment. While working on the final project for this course, my groupmates never got to use Issue Driven Project Management to its full potential due to time constraints, but it still proved to be very effective for organizing the project.
Coding Standards: Eslint is always yelling at me
Another software engineering concept I had experience in was coding standards. This concept is not just about using a linting tool like Eslint to clean up code, it is also about following standards to write clean code. When it comes to working as a team, coding standards help to make code look consistent all across the codebase. In the past, I have never used Eslint but just GitHub Actions in a pull request to lint my code. Eslint, when used in IntelliJ really likes to scream in your face at every little thing, which I find very annoying. After my experience with Eslint in this class, I prefer just keeping it off and just linting my code at the end. However, the “fix all Eslint errors” feature with IntelliJ is pretty effective.
Functional Programming: My love for Underscore.js
Although I have had some experience in software engineering, there is still a lot for me to learn. After all those WODs in this class, I’ve grown a liking for functional programming, which was using the Underscore.js library to help you manipulate arrays, objects, and arrays of objects better. I’ve found the WODs on functional programming to be the most difficult out of the whole class and I’ve started using Underscore.js more in my JavaScript code. It really gives an edge over just using your default ES6 map and filter functions, making your code even easier to read. My favorite function has to be _.where() from Underscore.js because it allows you to search an array of objects just by passing a key and value in object form. It’s much easier than using the filter function in ES6.
Final Group Project: My overall thoughts
Overall, the most I have learned about software engineering in this class was from the final group project. One of the biggest challenges in the final project was just getting the project started with our scattered ideas. Deciding on the name of the website, its logo, and the pages it should have the functionalities; it was hard to come to a consensus. In the real world, this project really made me value the role of product managers who have a whole vision for what a website should look like and it is just the web developers’ job to just code it. This project also taught me the importance of writing clean and readable code, especially when working in a group. A lot of time can be wasted when deciphering what someone’s code is doing. It can make it really difficult to add new functionality to your website when the previous code is very disorganized.