OnDeck

For this project, I was a frontend resource in a team of four total engineers to create the custom WordPress website for company, Ondeck.

This was an interesting project, to say the least... This project was a severe lesson in how communication is truly the most important, especially when working with a distributed team, and just how CRUCIAL good project management is. If you've got a PM that you love working with, let them know!!!

The project requirements called create modular building blocks through the creation of shortcodes with the handy, dandy shortcode UI plugin, Shortcake. This was before Gutenberg was integrated into WordPress Core, hence the creative solution.

The task was split up between frontend and backend engineers, with a project manager spearheading and leading our work. The backend engineers (one backend and one senior backend) would create the shortcode and integrate it into the WordPress WYSIWYG, and the frontend engineers (myself and one senior frontend) would style it appropriately.

Although there were client-approved documents that outlined exactly what sort of modules were to be created, what ended up being created during development did not really adhere to these documents.

Before I began my portion of the project, I made sure to read all of the requisite project kick-off notes. Being detail-oriented is how to be successful, after all. I noticed that there were some real discrepancies between the design comps and what I was tasked to work on. I decided to go through all of the documents that were available to check if there had maybe been some changes made to the approved comps and approved modules-- there were none.

So, I checked in with the Project Manager who then had me create a document detailing the modules that needed to be created and the modules that were not yet created. I was doing some project management, even as a frontend resource! After presenting my findings, I was told to correct the errors that I found.. and so I did, going into the custom plugin that backend had created to make corrections to the code.

I feel particularly proud of this project because I was empowered to direct something potentially disastrous to a solution. Despite not having the title of Senior at that time, I feel as though I was doing things that a Project Manager or Senior Engineer should have done.

The lesson learned here, as stated above, is that everyone regardless of whether they are senior engineers or not, must always do their due diligence and check their work against requirements. I understand that it is easy to get comfortable when working remotely, so sometimes it is easy to overlook things and get a little lazy.

However, we must always put our entire effort into each and every project because while it may be just another project for developers, another day in a long series of work days, it is a product that represents the company. For the client, this one project represents what the company has to offer.

Luckily, by having a team structure that required engineers to check each other's work with pull requests, as well as extensive documentation of client meetings and project requirements (the result of GOOD and enforced company processes), this project was able to launch after some course-correction.