At time of writing it’s now been around four months since I first started studying software engineering, and it’s amazing to see how much more I know now than I did at the start. It’s been a lot of work to try to learn what I have this semester, and I’ve still barely scratched the surface, but I can really feel it paying off. At the start of fall, all I had experienced working on was individual projects, never to be published and with little to no overhead. At most I had used GitHub to work on small java projects individually or in a small group, but even that had been without any formal structure to how work was being done. I had little no experience creating websites, and absolutely no idea how to deploy them. I knew that frameworks for web development were a thing that existed, but I knew next to nothing beyond that. After the work I’ve done in these past few months, I may not be the most skilled at anything but I feel like I’ve managed to accomplish at least some baseline level of competence. Truthfully, it’s a very gratifying feeling and I’m eager to keep working towards learning more in the future. On a smaller scale, I’ve learned the basics of JavaScript and found my extremely rudimentary knowledge of HTML and CSS much improved. With my newfound knowledge of React and Semantic UI, I’ve even learned how to build webpages that don’t look like they’re fresh out of the 90s! More than that though, I’ve learned so much more about what goes into creating a website than just creating individual pages. I know now how to store and access data from a MongoDB database, and how to tie that all together with Semantic UI and React using Meteor. I’ve learned how to do testing for JS and websites too, using TestCafe. I’ve used jUnit prior to test the aforementioned small java projects, but TestCafe felt like a whole new experience with its use to test websites rather than just pure code.
The cherry on top for me is that I know how to deploy websites now – I’ve learned how to use Digital Ocean to host websites, how to deploy from a computer using Meteor Up, and how to set up https and custom domain names. It still renders me a little giddy every time I think about how I’ve developed the toolkit now to be able to just make a site if I wanted to. I enjoy playing a game called Rocket League, and there’s a lot of great libraries for doing data analysis on replays from it. If I wanted to, I could go and create a website that displayed replays right now! And that’s just one possibility – I could do that for any number of cool ideas I have bouncing around in my brain at any given time, or for any new ones that come to me in the future. Having the knowledge now on how to create an actual, proper, functioning website feels so freeing to me, and I’m really glad I’ve put in the work to learn it.
Beyond even that though, I feel like I’ve learned so much about the process of creating software – especially in the realm of project management. Prior to this class, even when I’d worked with others, it had been a messy and unorganized affair, with people each having a single branch they worked on, pushing and pulling from main as they pleased. Now though, I’ve learned how to work better with a team using issue driven project management. Issue driven project management is a way to manage work being done on a project by separating the project up into different milestones, each of which improves the functionality of the previous, and the work done for each milestone into issues – small bite-sized tasks that can mostly be worked on independently of each other.
Honestly speaking it’s simply far more sensible than they way I’d worked on projects before; When everyone’s working on their own branches people aren’t going to be keeping perfect track of what’s been done, and a lot of work gets done multiple times. People will create code that functions all manners of different ways, and the end result can be a hodge-podge mess of a bunch of individually coherent pieces glued together at the seams. On the other hand, issue driven project management results in a far more cohesive end result and much better mimics the way people work in groups on everything else aside from computer science. If you’re in a group and need to make a poster, you don’t have everybody make their own version of it and then create some Frankenstein’s monster of a poster by cutting off the nicest pieces from each and stitching them together. That would result in a very flimsy and ugly poster, and so much work would go to waste. So why should you work like that when coding? The intangibility of what you’re working on means that it’s much easier for people to work on the same thing multiple times without realizing, so learning about issue driven project management has been a godsend for me when it comes to figuring out how to make sure that work gets done once and in such a way that it fits in with everyone else’s work in a cohesive manner.
Aside from working on my own projects though, I feel like I’ve learned much about giving back to the community. I’ve made use of many open source projects in the past, but every time I’ve thought of trying to contribute back to them, even in some small way, the size and complexity of the codebase for them has been far too daunting and I’ve ended up giving up. Now though, I feel like I have a far better grasp on how to help contribute, and even though I’m not going to be getting significant work done any open source projects any time soon I feel like I have the knowledge necessary to figure out where help is wanted.
Overall I’ve had a great time learning about software engineering so far, and despite the rigors I’ve went through, I’ve come out the other side feeling like everything was worth it. Learning about full stack development has been a great time, and I feel like everything I’ve learned will serve me well and continue to pay dividends far down the line. It’s been an enjoyable couple of months, and I’m looking forward to learning more in the future.