There is a lot of reflection to do. After my nth attempt at this course, I have come to a much more mature understanding of Software Engineering as a whole. In all this time, my understanding on the practice of developing software has gradually evolved from seeing it as a sweeping generalization to an appreciation of the individual parts. Each part works as a cog in the greater machine of this industry. This is to say, unless each part is well oiled and primed, an entire project can comepletely fall apart. Regardless of its place in the process, any part ranging from something as mundane as legible code to managing projects efficiently play crucial roles.
Legibility acts as a lobby boy. It stays in the background, never seen but its presence is always noticed. Personally, I do not have a good track record in coding standards. ESLint and I have a rather complicated relationship. Regardless, I can grasp the importance of writing code that can be read. Tackling the final project required making sure that I am not the only one that can decipher it. If it gets bad, I might not even be able to. Admittedly, I did end up using AI to reformat my code. Of course, that meant spending time to review it just to ensure there were no changes to the content; ultimately the same amount of time spent to reformat would be taken to review. Even while participating in athletic coding practices would require clean code. Losing precious time because I lost my place or because I could not find a bug is aggravating to say the least. Making every second count is important in any workflow seeking to prioritize efficiency, leaving set coding standards as a way to avoid confusion.
Aside from my own code, continuing to reinforce team playing skills was another crucial aspect of Software Engineering. Unless working on a passion project, it is unheard of to have a large scale project with a solo dev. Regardless of team size, being able to work comfortably with each member allows the project to flow smoothly. The team I was in for our lost & found project kept open communication lines and were honest about each other’s progress. Since we were able to keep track of our progress as a whole, we were able to finish a functional baseline version of our idea with room to add QoL improvements. We split our duties between frontend and backend allowing for efficient dessimation of work. Once one sub-team completed their duties, they would then move in to assist whoever else is still working on their issues. This way, we worked in almost a collapsing manner; that is to say we worked our way inwards from all sides. This would not have been possible if we did not keep strong communication between one another. While moving parts can allow for more efficiency, compartmentalization can also breed miscommunication. Should we have been working blind, I do not believe the application would even be functional unless one person does all the work.
I have also developed a fierce support for open source software (OSS), something I had already appreciated but found a new respect for its importance. Projects range from small hobby programs to entire systems like GNU and Linux. OSS allows an open sharing of new ideas and showcases of human creativity. This field is, in essence, still a science. Keeping a constant flow of ideas not only establishes connection between developers but also adds to the ever growing archive of internet history. While closed source software does have added security in the sense that source code is completely private, OSS protects the end user by allowing them to view all the software files individually. OSS gives power back to end-users, closing the gap between them and developers.
After another semester reaches its close, I am happy to say that I put in more work than my previous attempts. I spent time to actually grow from what I was learning rather than simply chasing a grade. While there can be an argument to be made regarding additional effort I could have put in, I recognize progress where it is due. Otherwise, how else can I keep good spirits?