The class has come to an end, and my team of three (for which I was the project manager) have created, in my opinion, a fantastic website for our client, Dr. Ann Willyard. The project - the iSeeGreen Search App, holds over 380,000 unique plant taxa, supports search/filter and sort operations, looks elegantly minimalist, lets users register/login and save plants to their own collections, and got deployed to https://iseegreen.azurewebsites.net! I spent so much time last week - 28 hours - getting the app deployed and full of data in a maintainable manner, but it was worth it in the end to see such a nice final product.

Despite the project absorbing so much of my time and certain aspects of it (*cough* Azureappservices *cough*) giving me grief, it was a surprisingly enjoyable project. Not only did I have a fun team of classmates who were competent in both programming and collaboration/communication, but I got to help create a powerful tool that has the potential to help lots of people. I’ve worked on lots of projects in the past that were fun to work on in theory - for instance, my Rust ray-tracing renderer - but didn’t offer the same kind of satisfaction as iSeeGreen did. Getting to meet Dr. Willyard, hearing about the kinds of things she wished she could do with her data, and being able to iteratively bring those dreams to life helped me connect with my project in a deeper and longer-lasting way - much in the same way I connected with the Hendrix Today app!

Of course, I have still only worked on a handful of client-oriented projects, and I know I still have a lot to learn. One of my more significant regrets for iSeeGreen is that we may have undercommunicated with our client. Although we scheduled meetings during all of the required client meeting periods over the semester and had insightful discussions on the direction of the project, I can’t help but wonder if more communication would have increased client satisfaction. Part of a developer’s job (or any kind of contract-based constructive work, really) is to communicate with the client and translate it into a satisfactory implementation that closely matches what the client needs, rather than what they said. All that to say, I’ve learned that communication and design - things like asking what use cases should be met and writing up a data model or database schema - are just as important as knowing how to implement any arbitrary model or schema. I don’t think this was an issue in our project, but it’s something I was aware of this time around and would like to practice more in the future.